Often times, applications cannot get rid of the database records for business rules. For example, if you are a cable TV provider, you might have a customer calling you to stop the National Geographic Channel subscription from next month. Ideally you would like to delete this record, but you can't do it until the effective date:( If you delete it, the next invoice will not be able to charge for this channel, although it's still being used.

Photo credits to Esteban Cavrico I was working on a web project that lets you delete some records using Ajax. The following is just an example, but you might be familiar with a similar code already: This code used to work when the DELETE endpoint was indeed under '/blog/posts'. However, at some point a developer wants to remove the '/blog' from all the endpoints to put them directly under '/posts'! You can see, in such cases it is very hard to catch the bug that would be caused by the faulty JS code.

Private methods, when used meaningfully, are a great tool for writing beautiful object oriented code. But as many other things in life, excess of private methods is bad, too! In my opinion, we use private methods to: 1.  isolate a block of code to be reused inside the class. 2.  extract code from another method for code readability. Now, taking these two use cases in mind, here's an easy conclusion:

Modules in Ruby are like classes with a few important differences. One of the differences is, a module cannot inherit from another module using the same syntax as class inheritance. However, its pretty easy to inherit a module's method into another module, by just using the include ModuleToInclude syntax. Here's an example if you are looking for one:

C# 5.0 (CTP version at this point) has support for async and await to allow clean implementation of non-blocking IO using a task-continuation model. I was just playing with it and here's the sample code to tease your brain. Tell me what is the output of this program?

No. You should not. Here's an example: If you are somehow mocking this static method, you are potentially making it dangerous for other places where this static method is used. Eventually, this will create red test results that are hard to find and make your tests dependent on each other.

Here's the code:

Well, anytime you have a lot of mocking, it is probably a smell. Particularly, a first smell is violation of the law of demeter. However, we were having discussion about whether or not we should write unit test for something like the following example: As you can see, this method actually does a quite important task. It invokes the search method with specific parameters that will determine your search results.

Ruby has a nice little keyword called unless, that checks the opposite of if. So, you are probably used to a code like this: return customer.first_name unless customer.nil? If you haven't used present? before, you can in fact turn the above unless into a more familiar and easy to understand if statement: return customer.first_name if customer.present? So, in most cases when you are using unless with a negative condition, you can use present?

Yes, if your constructor does something meaningful. This is just like another method and should be treated equally for unit testsing purpose. Here's an example that should need unit test: It looks simple, so testing it should be simple, too. I would only skip the default constuctors, as long as they don't do anything interesting. Comments Alexander Beletsky Sure, the constructors are methods too.. but they should not do anything more except internal initialization.