As full as it gets...

Ever wondered why do we use interfaces in programming. Of course I am talking about the main stream languages - C#, C++, Java etc. Many know all the text book reasons, some are obvious reasons - and some others- we seldom come across practically. The obvious reasons -

• Easily extendable(meaning a class can implement multiple interfaces etc..).
• Standard contracts. You have the common methods in the interface. And different Classes can implement the logic in their own way. The client calls the class that is applicable.

It all is beautiful, Agreed. But nonetheless the actual beauty of using an interface lies in the fact that TDD(Test Driven Development) becomes bloody easy. Everything falls nicely into place.

Many developers don't really understand what unit-testing is all about. They write some obviously passing unit tests and that's that. Not much effort really goes into writing good unit-tests. Well, you can't always blame the guy who is coding. There are many hidden implications here.

First of all, if he is writing some new code which is using many other existing classes(utility classes or core business specific classes or anything for that matter), its not always possible to unit-test his new code. Reason - The old classes were written without the "testable" approach in mind. Secondly, if this new code has some Database calls or Web Service calls, then its tricky to write unit tests (or at least that seems to be the myth out in the wild!). So, the guy goes.."Nahh..Forget it. Its hard. Am sure my code works OK. No need to unit-test. Unnecessary effort"

In the first case - you should have followed the TDD approach when you wrote the old classes to begin with. Try to refactor the code into what I call the 'Testable Interface' design.

In the second case - IT IS POSSIBLE. You just have to mock the DB calls and put the web service calls behind an interface. Again Testable Interface Design.

Testable Interface Design:

If you have to write a class to do,

1. Call a web service and get some output A.
2. Process that output(some business logic) into an output B.
3. Write B to the database.

If I ask developers to unit test this, many would write some code which tests the whole process end - end, all the 3 steps. But technically our job is to test ONLY step 2. The web service call is external to your code, so you can't control it. So you shouldn't write a test that depends on the output A. And coming to the Database call, you shouldn't write a test which actually writes stuff into a test database. That writing might fail if there is a bug in the Stored Procedure, which is again not your problem, I mean not your code's problem.

So just test Step 2 - business logic. But how? If you write a test which calls the method, it goes through all the 3 steps. How to manipulate the functionality of that method, so that it only does Step 2. That's where Mocking comes in. The most cutest thing I laid my eyes on since Meg Ryan!

You just have to mock the output of the webservice and the database and just test your business logic. Hmmm sounds nice, but what's mocking. Mocking is nothing but making the objects return what you want. So if you can find a way to make the webservice(obj 1) and the database(obj 2) to return some output, your problem is solved.

First put both the client code that calls the WebService and the code that writes stuff to the database in an INTERFACE.

Implement its logic in a class,

And write your main code like this,(Please click on it to view clearly)

So you basically are allowing the client to pass an implementation of the Interface IExternalCalls in one of the constructors. Hence the client can control the functionality of that interface i.e., the methods which call the WebService and interact with the DB are under your control. FINALLY...Huff..!

So your test code goes something like this (am using the Moq library - very simple to use)

See......Simple eh! :)

1. When you have spent at least 82% of the weekend in a radius of 100 meters from your front door.(Going out for a hair-cur, groceries etc won't count as an outdoor activity)
2. You order a virgin margarita when the girl's having a beer.
3. When your arms are way more healthier than the rest of your body!!!
4. If you keep thinking about why you won't get laid for most part of your day and decide to write a blog about it. Something like this.
5. Even after 4 dates you don't/can't touch him/her other than a handshake or while crossing a busy road.
6. The 1st thing you say to your date after the initial pleasantries falls into the below categories (and/or) similar ones

• Jayalalitha's election win
• Dhoni's new bald look
• Your views on the whereabouts of WikiLeaks founder

7. You take her to Fast and the Furious 5 and act like that's the most coolest movie ever.
8. When you openly make fun of her shopping addiction...they all have it and YOU JUST SHOULDN'T GO THERE...TRUST ME ON THIS.
9. When she catches you staring at her friend's you-know-what.
10. A corollary to the above: When the you-know-what you were staring at belong to her sister.....you can forget the phrase getting laid for a period of 7 months or until her next birthday whichever is the farthest.