Monday, February 8, 2016

Unit Tests Assertion Coverage

A unit test case is made of three parts - the "given", "when", "then". The "given" is the piece of code that set's up mock objects, data that needs available and dependencies that need to be injected. The "then" will execute the method under test. The "then" verifies the results of the execution of the method under test.

Too often it is observed that the unit tests do not have enough of the "then" statements that verifies the return results. This happens more often in cases where existing code running in production does not have sufficient unit tests available. When new features are built on top of the existing code it is often difficult to write proper unit tests with good verifications and assertions.

The problem described above is also a symptom of a team's focus on code coverage. While code coverage is a good metric to observe and use it only proves that the application code was executed. A unit test case with "given" & "when" and no "then" will also produce a good code coverage metric. This kind of unit test is not a good test because the verifications do not exist.

I recently tried out a solution to this problem with really good success. The solution was to capture the return value of the "then" piece of the unit test case and run it through the jackson object mapper. The result is a JSON representation of the actual return value of the method under test. Save this JSON in one of the files in src/test/resources folder. This makes up the "expected json" of the unit test. In the unit test, now every time the method under test is executed, take the actual return value, again convert it to json and compare it with the "expected json" that is saved in src/test/resources folder.

This approach is also described as Characterization Tests. As described on the wiki:
In computer programming, a characterization test is a means to describe (characterize) the actual behavior of an existing piece of software, and therefore protect existing behavior of legacy code against unintended changes via automated testing. This term was coined by Michael Feathers. [1]
This approach allows us to gain the critical "Assertion Coverage" from a test case. Assertion Coverage is the measure of how much of the data produced by the method under test is valid. Contrary to what it sounds like, this approach does not produce any metric like the code coverage metrics, its not something we can see in red or green colors. The benefit is clearly visible though.

Another important benefit of this approach is the "expected json" that was produced serves as a documentation of what a specific method produces. The entire object is converted to JSON and thus we can get a good visual of the data that flows through the code.

In the next post I will elaborate more on this approach with an example.

Sunday, May 10, 2015

React over Angular - my take

I took some time to learn React JS in the last few months. I created my little version of todomvc like application, created the same application using React and using Angular. The code lives here:


Here is what I found. Overall I liked React much more than Angular for the following reasons:

  1. My debugging experience was much better. Angular brings JS into HTML and React brought HTML into JS. At first I cringed a little at the thought of having HTML within JS. As I kept building the application though it was much easier to debug issues. 
    1. First things first -- there was only one file to look at. Nothing more. All my JS and HTML is within one single file. Unlike Angular JS where I had to look at a directive, an HTML and a controller.
    2. JSX caught a lot of errors at compile time. This gave me more confidence. With the angular app I found errors at run time AND after a few hours of that error introduced.
    3. Easier to refactor - The above reasons made it easier to refactor the code as well.
  2. Componentization came naturally. With this I mean creating web components that can be distributed and reused much more easily. Again - having a single file helped a lot. I will be writing more about componentization in later posts.
  3. React definitely had a very small learning curve, much smaller than angular. It was much easier to explain React than Angular to my friends who knew nothing about both.
  4. Aligns well to Page Object pattern that is popular in testing circles. Although this is not the best of the reasons - it is worth a mention.
  5. The idea behind React makes complete sense. The part that model is the state and HTML is the projection of state and that only part of HTML that has changed is the one that is modified.
So - would I use React on my next project? This is a difficult question to answer. I would certainly advocate for it. A lot depends on the organization / project though. If there are Angular / any other framework experts out there and things are done well - there is no need to rock the boat.

Sunday, August 3, 2014

Fuzzy Avenger

My latest new project on Github is Fuzzy Avenger.

Why was this created?

This project started off as a learning exercise. This weekend I wanted to learn Akka with Java. In the process I created this github project to capture my learnings. The folders one - five in here is where that learning was captured. As I did that I realized a simple utility can be created that can be used with any traditional java code - specially unit tests or just for curious minds. This utility will process a list, apply a long running function (like making service calls) to each element in the list, capture results, aggregate them and will return the results. The results will be returned in the order - one for each element in the input list. Thus, this utility was created.

Why would I use this?

I would recommend not to use this in production code, yet.
Use this utility in your unit tests to exercise parallel processing / concurrency. For curious minds - to try out some instrumentation on your services For learning To provide me some feedback, if this is interesting, helpful and what updates can be made

Thursday, April 24, 2014

Everyday Math from McGraw Hill Education

These days I am working on the version 4 of the Everyday Math program with McGraw Hill Education. The marketing team here prepared this video about the product we are building these days. The product is Everyday Math 4 that is targeted to students and teachers for grades K-6 and this will be launching in June for the 2014-15 school years.
The video features the authors of the EM, product sponsors, UX designers and academic designers from the Chicago office and showcases the product we are building.

More information on Everyday Math program: 

Friday, April 19, 2013

Presentation at Quest 2013

Terry and I were at the Quest Conference 2013 in Chicago this week. We met several professional and people in the field of QA and also did our presentation.

The slides are here: