Unit Testing for Complex Features

SOFTWARE DEVELOPMENT

WorkingMouse has de­vel­oped an ex­per­i­men­tal frame­work to con­tinue to re­fine our processes as we learn and adapt to new tech­nolo­gies and ways of work­ing. Our ap­proach al­lows any­one within the com­pany to pro­pose an ex­per­i­ment, trial it and doc­u­ment the re­sults. Some soft­ware de­vel­op­ment ex­per­i­ments suc­ceed and are adopted widely across the com­pany while oth­ers fail. The pur­pose of this ar­ti­cle is to share the find­ings of one of our re­cent suc­cess­ful ex­per­i­ments con­cern­ing us­ing unit-test dri­ven de­vel­op­ment for com­plex fea­tures.

Summary

Based on our sci­en­tific struc­ture, the ex­per­i­ment was sum­marised by look­ing at why, what and how. The cur­rent land­scape is pre­dom­i­nantly cen­tred around end to end test­ing which sim­u­lates user be­hav­iour.

We be­lieve that writ­ing unit tests be­fore im­ple­ment­ing a change will re­sult in faster im­ple­men­ta­tion and less risk of prob­lems with the change.

We will be ex­per­i­ment­ing by writ­ing unit tests for a change in­volv­ing com­plex logic be­fore im­ple­ment­ing the change it­self.

We will know this ex­per­i­ment is a suc­cess when the unit tests are pass­ing, the change is im­ple­mented and passes UAT.

End to end tests vs unit tests

Firstly, lets re-visit the dif­fer­ences be­tween unit test­ing and end to end test­ing. The idea of a unit, is to break down the code into small, eas­ily testable parts. It could be a sin­gle func­tion, class or in our case, com­plex al­go­rithm. This dif­fers from an end to end test where you’re test­ing the en­tire ap­pli­ca­tion. The point of an end to end test is to sim­u­late how a user would use the ap­pli­ca­tion. Scratch cre­ates a good tem­plate around this. If I do X then I ex­pect to see XYZ.

Method

To eval­u­ate the suc­cess, test dri­ven de­vel­op­ment was adopted as part of four pieces of func­tion­al­ity on a com­plex pub­lic sec­tor pro­ject. The team im­ple­mented a num­ber of unit tests for the four pieces of func­tion­al­ity while still cre­at­ing a sig­nif­i­cant num­ber of end-to-end tests.

Evaluating Unit Test-Driven Development

  • During the ex­per­i­ment, our end-to-end tests rou­tinely failed with a high num­ber of false neg­a­tives, whereas the unit tests were rock solid - no false neg­a­tives.
  • The amount of main­te­nance re­quired for the unit tests was very low - al­most none.
  • The amount of main­te­nance for the ex­ist­ing end-to-end tests was very high - usu­ally in the or­der of a day or two of ef­fort a week.
  • Our con­fi­dence in the ar­eas cov­ered in the unit tests was high.
  • The unit tests on the Jenkins board were al­ways green.
  • They are quick and easy to run com­pared to the end-to-end tests.

Going for­ward

Unit tests work well as an­other tool in our toolkit to com­pli­ment our end-to-end tests.

They are not in­tended as a re­place­ment for end-to-end tests, but given they’re more re­li­able, faster and lower main­te­nance, they are a good op­tion in some sit­u­a­tions.

The biggest ben­e­fit is for long-run­ning prod­ucts with fre­quent main­te­nance (eg. large pub­lic sec­tor pro­jects), or for ar­eas of code where the logic is com­plex and dif­fi­cult to de­ci­pher when re­sults go wrong.

Everyone should keep an eye out for ap­pro­pri­ate op­por­tu­ni­ties where unit tests would pro­vide value.

Industry the­ory on unit test­ing

Before the ex­per­i­ment, we gauged how the in­dus­try per­ceived unit test­ing. Google’s Mike Wacker summed up the value of unit test­ing in this blog. Unit tests are fast, re­li­able and help iso­late fea­tures.

The other key ben­e­fit that we saw re­flected in our re­sults was the speed to find­ing and fix­ing bugs. With end-to-end tests, you have to wait for the soft­ware to be built, then for it to be de­ployed, and fi­nally for all end-to-end tests to run.

Since the bugs are found early in unit test­ing, it helps in re­duc­ing the cost of bug fixes.

While this is a great tool to have in our toolkit for com­plex logic, there is still sig­nif­i­cant value in run­ning end to end tests.

Discover Software
Secrets

ABOUT THE AUTHOR

Steven Dangerfield

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion