Tuesday, November 25, 2014

What is Mock object and Mocking framework in unit testing?


This is a buzz word in development for some time. TDD got into picture when Agile storm hit the software development industry even though they don't have much relation. Let's look at what is mean by TDD ie Test Driven Development.

As the meaning says the software development process is driven by test in a TDD environment.  Developers need to write automated test case first which will fail obviously. Then write code to make that test passing. When we say automated test case, its again a program which is calling the code / function intended to develop to fulfill the requirements.

Once one test passes, developer needs to think about next scenario and writes test for that scenario. First it will fail, then we will change the production code to pass that test. Finally we will be ending in a scenario where there will be many test cases / test function for one production function. The idea is whatever the developer thinks, it needs to be recorded in the form of test cases. In other words even if, there is not much documentation, by looking at the tests new developers should be able to understand the intentions of particular function.

After all the test cases are completed, the production code needs to be re-factored to standards. Use of proper patterns, making sure its adhering to SOLID principles are coming in this phase. Normally delivery oriented companies or companies want to make more profits and budget constraint projects never go for this step. If they do so  it will surely byte them back in future during maintenance phase of the project.

We talked about writing tests, what is the type of test case or what do they test? Is it load test, functionality test or integration tests? Can we get rid of QA department if we bring TDD methodology?

Never. In TDD we are writing unit tests only. Developer tests his own API to make sure that, his piece of code / function will work as expected in all the scenarios. Other type of test such as functionality testing, integration testing & load testing needs to be carried by the QA / Testing department.

Unit testing

Unit as the name says testing small units of program. In most of the programming languages today,  the smallest unit of program which can be tested is function / method. So we are testing functions via unit testing. We can say its part of API testing as well. But its not full API Testing. API Testing includes more factors. 

Important thing to remember here is, unit test is to test one single unit. Not its upstream or downstream dependencies

Why this is more important? If we take any layered application, the business logic is supposed to be in single layer which we normally call as business access layer. Business logic is nothing but  collection of if...else and looping code based on client's requirements. So the unit testing is more applicable on business layer. If we take data access layer, there are not much code expected other than the database interactions and those are pretty static in all the projects. So lets take one scenario to get the idea clear.

Unit testing in real scenario

Suppose, we are developing an address book application. We need to validate names for special characters & validate the Zip code (Pincode / postal code in India) whether its real or not.That validation logic obviously comes in business layer. (Of course UI will have validation but its optional. BL can never avoid it)

In this situation, when we write the test method for BL.InsertPerson(Person p), we will be obviously calling a web service which will return true / false for a given zip code. During development time we will be running the tests so many times and if we try to call that web service all the times, it will take us precious time. So what to do?

Answer is Mock object. In an ideal case, if we are following SOLID principles, there would be an IZipcodeValidator interface with Validate() method. Mock this interface and return true always. So that we can unit test the InsertPerson() method. Then what about the data access layer. The default data access layer will obviously call database and try to save the data in it. But do we really need the database interaction when developing the business layer?

No. Remember we are unit testing single unit of code not its dependencies such as data access or  zip code validator. The aim of the unit tests in this case is to make sure 
  • If the parameters into BL.InsertPerson is wrong ensure there is exception
  • If the parameters are valid, make sure the IDataAccess.Insert() is called.
  • More test scenarios like, 
    • If the data access throws exception BL.InsertPerson should not eat it
    • More (as of me it goes to infinity:))
If we are not calling the real data access, how do we make sure the business layer function is working proper. As we saw above,its the magic of mock object. It knows what to do for particular scenario. How do we create mock objects? Do we need to write mock classes?


Wiki says "Mock objects are simulated objects that mimic the behavior or real objects in controlled ways". What does it mean? We are creating some dummy objects (simulated) which can be injected as dependency in the class under test (mimic the behavior). Important thing to remember is without knowledge in dependency injects its very difficult to adopt the TDD concept. The methods in those mock objects will return the value to suit to the test case (controlled ways). There are 2 ways to create mock objects.

Hand coded mocks / fakes

Here we just implement the same interface into one more class and return values appropriately for different test cases. If different test cases needs the behavior in different manner we need to create many fake classes. This is not practical at all.

Mock objects using framework

The mocking framework / library can be just another .Net / Java library which can create the mock object for us. We can ask the library  "get me mock object for my interface". Then we can set rules on that returned object on how to behave when particular method is called or event fired ets... Once the mock object is set it can be injected into the code which we are testing.

I know its very hard to explain by writing. So it would be better, if we can spend some time on youtube which explains how it can be done in real life. 

Comparing mocking frameworks

We discussed about mocking library. Are there many libraries? If so which library is the best? I still didn't get the answer. We have started using Moq library to evaluate it. There are many comparisons in internet. Unfortunately none of them are recommending one library. As of my experiment with Moq, I will suggest that for simple projects. The main reason is that, Moq is the one most of the fellow developers are using :)

Links to mocking library comparisons


There are more concepts in unit testing such as stubbing and faking. All are related but slightly different.

Happy testing!!!

Tuesday, November 18, 2014

State pattern v/s Orchestrator


Normally in programming we encounter scenarios where we need to carry out many operations in sequence. The sequence of operations can change based on client's business requirement changes. At this point we can assume that there is no parallelism required. How do we code such a scenario efficiently?

To tackle this, either we can write everything in single function or we can split the entire operation as step functions and have another controller function calling the those in the required order. Some people who are inspired by patterns go for pattern oriented programming and most of them end up in state pattern.

Before we go further, if anybody still thinking that what is the problem in writing the code in sequence or in single function? I would suggest get better understanding about the below concepts of programming.

  • Object Oriented Programming
  • Single Responsibility Principle
  • Re-usability
  • Separation of concerns

State pattern

State pattern defines the system as discrete states of object where each state knows what are it's next  possible states. It also has mechanism for changing the state upon any event. Events can be anything such as keyboard input, UI action such as button click, a service invocation, a timer elapsed event etc...

There are defined ways and many libraries available as well which helps us to implement state pattern. Some libraries support encapsulating different states into different classes and we can connect them. But as the basic nature is one state knowing other, its very difficult to change the sequence without changing the state classes.

Below are some links which contains implementation of state pattern and libraries.

State pattern v/s state machine

Now most of us will get a question in our mind. What is the difference between state pattern and state machine. As of my understanding state pattern is just another state machine implementation which is clean and dead simple. We can build state machine using iterator / yieldWindows Workflow Foundation , or more simpler stateless library.

Orchestrator / Sequencer pattern

We have seen what is state pattern. But is that suitable in the requirement mentioned at the beginning of this post?  According to the requirements the flow can change based on business requirements ie  logic in one step should not tell what is my next step . In state pattern each state should know about other state and tell the engine to go that particular step. If we use that state pattern we cannot build independent steps which can be interchangeable. In most of the cases, steps will be dependent each other. But our requirement is specifically about independent steps. So what is the alternative by honoring all the programming principles.

The solution leads towards orchestrator or sequencer pattern where we can define the sequence and just start the sequence by giving context which the steps are going to manipulate. It will take steps one by one and execute. I was not able to relate this requirement with any of the GOF design pattern, that's why I had to use orchestrator. Template pattern in GOF is somewhat similar. But in that we could see implementation class contains all the operation methods which seems we are violating the SRP in SOLID. 

What is Orchestrator pattern requirement

  • It needs to provide an abstraction (preferably interface) to create concrete step implementation classes.
  • Support for receiving data context into the steps.
  • It should be having support for defining / sequencing our steps.
  • A StartExecution method
  • Prefer 2 modes of execution
    • Pipe line mode - Returned value of one step should be feed as input of next step
    • Normal - All the execution methods in steps will get the context passed via StartExecution method.
A sample implementation is in progress. Hopefully I can share in next post.

Difference between state pattern and orchestrator (Sequencer)

Summarizing the differences between state pattern and sequencer. State pattern requires one state to know other. If the logic changes we need to modify the concrete state classes. In orchestrator the states/steps are independent.

Tuesday, November 11, 2014

Simple interface based programming

For some long I was searching for a good article which explains how to use interface in .Net programming. It is not for a developer who is passionate in programming, got good knowledge in object oriented programming and comes with computer science degree. But for people who came into the field because others compelled and not having computer science background. At some point I thought of writing one myself. But I was able to find a good one. Below are the link(s). I will be updating if I came across another one.


Tuesday, November 4, 2014

.Net Access modifiers - Revisited

This is intended mainly for beginners to enforce their understanding about access modifiers used in .Net. We are going to discuss it in a question answer fashion. Read the below MSDN link which explains the topic and try to answer the questions.

  1. Is there any method even a hack, we can access private members from other class?
  2. If we can access private member via some mechanism what is the meaning of all these access modifiers?
  3. We are using access modifiers to restrict the access to fields and functions. Do we need any user name and password to access the variables? 
  4. Can't we program if there is no concept of access modifiers in the language? What are the advantage of restricting access?
  5. Can we have same namespace in 2 different assemblies? If so can I access internal classes in other assembly which are in same namespace?
  6. Can we have a public method inside internal class? What is the specialty?
  7. Can a public method return an internal type?
  8. Can we have protected class in any scenario? Where all we can use it?
  9. There is a public class named A.Can I have a protected class in same name A inside class A?
  10. If we make the constructor as private, will that class be unusable for ever?
  11. There is a public method which returns a public interface. In the method body can we have 'return new ImplClass();' where the ImplClass is internal / protected / private?
  12. Can a public class inherit internal class?
  13. Can a class inherit a class which is declared inside the same class?
  14. Can a public class expose a property which is of internal class type?
  15. Are the access modifiers mutually exclusive in .Net? Can I have more than one access modifiers for single member?
  16. Does 'sealed' access modifier seal the class for ever? Will that class create dead code in the assembly?
  17. Can we have protected static methods in non static class?
  18. Can we have protected method inside static class?
  19. Can we have public static constructor in a non-static class?
  20. Can I declare static variable inside a method?
  21. Can we have a member variable in a class of same type? Will that cause infinite recursive loop?
  22. When I tried the above scenario, I got StackOverflowException? Why its so?
Initially I thought I should be writing 2 posts so that when trying to answer these questions you don't get the temptation to look at the answer. Later sometime, the thought process changed. We are all professionals and true professionals can never lie to his profession. We are not trying this to get marks or pass exam here. This is just for gaining knowledge or understanding our level of OOP knowledge. So answers are there in this post only.
  1. Yes there is. Using reflection we can access the private properties or call private methods of other class / object. 
  2. .Net is managed the run time knows what are the types. But object orientation started before the managed environments. In that world it has sense. Even in .Net there are some framework classes whose members cannot be invoked via reflection.
  3. This is really childish when I asked this during one interview, he really started explaining about ASP.Net membership. He was a developer born into ASP.Net and according to him .Net is for ASP.Net. The access modifiers control the callers / consumers of the class in object creation and usage of it's members through objects. When we say via objects, it might be in a method in same inheritance hierarchy using 'this' or 'base' keywords.
  4. We can program even if there is no access modifiers in the language. In that case everything will be public. Below are the advantages of access modifiers
    1. Refactoring - Suppose we need to re-factor a method, by adding one more argument. If the method is private we need to care about only one class to get successful compilation. In case you are working in huge legacy code base (I am now working in a code base which is 10+ years old,contains more than 300 projects) and the method is public, getting compiled in first shot is a nightmare.
    2. Library development - There is no access modifiers in language and we are developing a library which has a method WeatherAtLocation GetWeatherAsync(location) for getting the weather information from a web service asynchronously and returns a structure which has the parameter location and the temperature. The method temporarily stores the location in a class level variable. Its obviously public. By the time our async web request to the actual web service completes the caller can change the value in member variable. So when we return the result it has a different location. 
  5. No. Namespaces has nothing to do with internal access modifier.
  6. Yes we can. But effectively the access of that method will be internal as the contained type is internal.There is one blog post by Eric on this.
  7. No. The public method is supposed to call by classes in other assemblies. If it returns an internal type, which is restricted to classes in other assemblies, we are violating the internal 
  8. Yes if we are declaring a class inside another class it can be protected. We can create object of this protected class in members of same class and all its derived class and its members regardless of assembly.
  9. Yes we can have. If we create object from outside, it will create object of outer class A. If the object creation is inside a member function of outer class A it will be the nested/protected class A.
  10. No. Private means accessible to all the members in the same class. If the class is public / internal, we can have a public / internal static method which creates the object and returns the same. Singleton uses this technique.
  11. Yes. The public method is returning public interface type. The interface members are permitted to be called from classes in other assemblies.
  12. No. If we do so, we are expanding the reach of internal.
  13. No. A class cannot inherit nested class inside it.
  14. No. The property is public but type is internal. So there is no meaning in returning the Type via  property. Similar to Qn 7.
  15. Yes. Some are mutually exclusive. We can have protected internal as combination. It tells that the method can be accessed in any inherited class regardless of which assembly OR in any class inside same assembly.
  16. Sealed modifier for the declaration. If applied on class it means the class cannot be inherited.If on method it cannot be overriden.
  17. Yes we can have static protected members. Those will be accessible in same class or inherited classes.
  18. We cannot have protected instance methods. In fact no instance members. Also we cannot have protected static methods inside static class. There is no inheritance support.in static classes.
  19. No. Access modifiers are not allowed on static constructor as its not callable from our code. Static constructors are supposed to execute when that type is first used regardless of where from that call originated and to which member. So it doesn't make sense.
  20. No. This was supported in C. But not in .Net.
  21. Yes we can have a member variable inside the class which is of same type. That won't cause any infinite loop.Otherwise linked list would not have been possible.
  22. If we just declare, there wont be any issue. But if we try to instantiate that object in the constructor without any condition check or initiate the object in the same line of declaration, it will throw StackOverflowException.

When I started, I thought there would be limited questions. But there are many. May be the compiler team at Microsoft will be having near full list as their unit test cases. Once I get some time I will surely tag / group these questions as Static,Inheritance etc...