Igor's Blog

I had to write very simple counting method today. I started with a unit test that pretty much executes a method (which increment a count) and asserted that the count was incremented. This is the test that I wrote:

public void testShouldRecordSystemException(){
     exceptionMonitor.recordSystemException();
     assertTrue(exceptionMonitor.getCurrentCount());
}

and this is the code that I was intending to write:

public void recordSystemException() {
storeNewTotal(++currentCount);
}

The problems with this test are:
- exposing internal state and breaking encapsulation with getCurrentCount() without anybody using it. (Yes, I know that I can make it protected instead of private, but this is not good enough for me. Changing private methods to protected in order to be tested is a topic, hugely discussed already in the blogsphere and I don’t have too much to add. I share the opinion that exposing private methods to protected just for testing looks like design smell and I try to avoid it. However, from time to time, I could make a method protected just for testing if this is the most pragmatic thing to do).
- This is pure state based testing. Although, sometimes state based testing is the better solution in many other cases verifying behavior is leading to much better design.

As a result, this small test reminded me about one presentation that I gave in our office about a year ago. The presentation is about “Mocking Abuse” but the final point of that presentation is that there is a middle ground between state base testing and interaction base testing (using mocks) that I call “verifying observable behavior”.

What that means is that this test should be changed to observe the behavior instead of verifying the object state:

public void testShouldRecordSystemException(){
         assertEqual(1, exceptionMonitor.recordSystemException());
}

What happened here is that the method recordSystemException() changed its return type from void to int:

public int recordSystemException() {
   storeNewTotal(++currentCount);
   return currentCount;
}

The first question that comes to mind is how to verify that the method executes correctly because you can pass the test above with implementation like:

public int recordSystemException() {
    return 1;
}

This is where the thinking about testing state vs verifying behavior should change. In practice, in order to verify behavior, we perform series of steps. Similarly, in mathematics we have so called “Mathematical induction”. Very simplistically put, a given statement is true for all natural numbers if the statement is true for 1, 2 …. n, and n + 1. Similarly, just one verification for verifying observable behavior is not enough:

public void testShouldRecordSystemException(){
     for(int n = 1; n< 5; n++){

       assertEquals(n, exceptionMonitor.recordSystemException());

     }
}

Now, this test should make me implement the right behavior.

That is not a ground braking technique or something not widely known. This is just a change in the way of thinking about design and testing. What is more, in functional languages like Ruby and Python this kind of thinking is encouraged from the fact that every method (function) has always a return value, which allows for observing the behavior of every method.

So, back to the presentation that I mention earlier, it is about something similar. Generally, in our desire to avoid state based testing (which sometimes leads to poorer design, braking encapsulation and so on) we go to the other extreme with interactive testing using mocks (exposing implementation being one of the negative consequences). I already wrote way back about this development behavior in Stubs or Mocks and State or Behavior.

This presentation is building the case on top of those two blog posts that mocks are not the new silver bullet and there is a middle ground between state based testing and interactive based testing that I call verifying observable behavior.

Mock Abuse!

As usual, any feedbacks are welcome!

Labels: design, mocks, testing

For a long time, I am struggling to find my job title (yes, we put whatever titles we want in our company). Coming from a highly business (financial) background, I had hard time defining the title of my position in the IT world.

I can’t call my self true “Software Engineer” because this title applies working in very technically oriented domains. “Software Developer” sounds good but since it is widely accepted term, it means different things to different people. Finally, I picked up “Business Developer”. This title was supposed to mean that I am very interested in solving business problems with any means possible (including prioritization, optimization of business workflows and processes and so on). Most importantly, however, it is about abstracting business models and managing the complexity of a business through a sophisticated use of software as a tool.

Yes, you can imagine that this didn’t work out the way I intended to. Almost of all of the people thought about “Business Developer” to mean a person who develops the business of a company in a way of increasing the market share, market awareness and finding new clients (or something like that) .

Later on, I realized that although sometimes I do provide small business optimizations and improvements most of the time I just solve pure software problems. Very often, I am solving those types of problem through heavy use of Google search. I search for similar problems and how other people solved them or didn’t solve them and then try to modify and apply the solution for my problem at hand. That’s why I decided that my title should be not something like “Java Developer” or “Ruby Developer” but rather “Google Developer”, meaning I can solve the problem in any language and tool with some extensive research on the web.

Well, “Google Developer” probably means that I am a developer working for Google, so logically the next one coming to mine is “Search Developer” or “Research Developer”. As you can see, both titles have different meaning than what I want to imply. For a while, I just give up and I came back to “Software Developer”.

Not far ago, I was involved with a huge enterprise project. What I reconfirmed there was that usually the business people give requirements according to which a new software system should be built. However, based on many miscommunications, misunderstandings, different context, simple mistakes, a lot of compromises and the amount of time that takes to build an application the abstract business model together with the business workflows and processes built by the (gigantic) software team are not exactly as the business envisioned them (and sometimes even dramatically different).

Very often the business (since it spent so much money for this) is forced to use and adjust to this new (different) business model. After a while, the whole business behavior of a department or an organization is determined by this new business model.

So, there you go! It came out to me that no matter whether the business likes it or not, I am building and redesigning the business model, workflows and processes while building new software business systems. Based on this reasoning, I am now considering the titles “Business Modeling” or “Business Transformer”.

And yes, they are still not on the target. “Business Modeling” is very good but it should be “Business Modeler”, which doesn’t sound good. “Business Transformer” sounds more like Robocop or something like that.

Finally, I am back to just “Software Developer” whatever this means. It is difficult to escape the common understanding (misunderstanding) for what you do or want to do.

Any other suggestions or similar thoughts?