Latest News

We, at Bridge In Tech, we embrace the power of code for positive change. We prioritize people, creating space for both professional and personal growth.
bt_bb_section_bottom_section_coverage_image

Improving unit test coverage with scenario based development

The majority of developers really love writing code and they love to find ways to bring to life a new functionality or a new product. They also love changing or fixing existing features. 

 

The reward they get is actually the fact that they made that possible. Their reward is creating something someone will use and enjoy.  

Usually they are not that invested in what the functionality is but they do care a lot about making it real.  

The vast majority of the developers find their sense of achievement in the creation of that piece of functionality. When they see the product in the final stages, they know exactly what they created in that product, even when it is not visible in the product as the users see it.  

 

But I doubt anyone has ever heard a developer being proud or even a bit satisfied with the number and quality of the unit tests they’ve written or the documentation supporting their piece of functionality. I know I never did.  

 

But they do write the unit tests and they do write the documentation and participate in any process thrown their way for that feeling of achievement they get when their code is part of a product. And all the rest of the process is just the cost of doing business for that feeling of success they have when their piece of code is in the product.  

 

And they do see the benefits of unit tests. They enjoy the confidence they have in their code’s resilience all supported by the unit tests.  

 

And seeing how useful unit tests are, we define processes and metrics and we set in stone rules to follow, targets to reach for unit test coverage. And they do fit some products and some teams.  

 

But at times, we consider the industry standards as rules for our company and maybe we miss the point of the unit tests and we switch focus on having 90% of the code covered by unit tests.  

And then that 90% unit test coverage is the norm and the baseline for any development work.  

The point of unit tests is to ensure the units we develop work as intended and ensure further changes don’t affect the intended behaviour.  

Without going into very specific implementation details, a higher level of coverage is helpful in some types of development and a way lower coverage is needed for others.  

 

And sometimes we miss the line between what is actually valuable and what is too much or too little.  

 

And then a lot of development effort is spent in writing and maintaining tests which don’t bring much or any value to the quality of the code. But more often than not, that unhelpful target is hindering the development process.   

As for the developers, even when they reach 99% coverage they don’t leave work feeling that sense of accomplishment. But they do feel dread. And the product is not better or less buggy and it is not released faster because of it.  

 

Scenario based development is one of the useful tools we could employ to regain that sense of accomplishment in developing new functionalities or making the existing ones even more interesting.  

 

The technical outcome of a scenario based development solution in this situation would be: 

  •  to redefine valuable metrics fit for the product and the team  
  • and tailor different metrics for different types of development within the architecture of the product.  

 

But the actual outcome is bringing back that feeling of we achieved something meaningful when we develop and test relevant code.  It goes without saying that less time wasted in meaningless tasks would lead to creating more meaningful code which translates to faster time to market and usually less defects. But that again is a collateral outcome of most scenario based development solutions.  

Share