Writing Better Code with Unit Testing
There are probably hundreds of dos and don’ts for writing good code. This list might vary for different languages or frameworks, and some of these guidelines may conflict with each other. In fact, in addition to using these guidelines, developers are often expected to use common sense as well. Design patterns are a classic example of this dilemma; if you start using them blindly without proper understanding and the exact use case then you will soon find that those design patters will turn into anti-patterns.
The same goes for unit test cases. In unit testing, you perform testing on the “smallest” unit or component of your application. Writing unit test cases is not easy, and maintaining them takes additional effort. Every time that you make changes in your component, chances are high that you will either need to add more cases or update already written cases. This article will dive into how to write better code with unit testing.
Use case
Let’s consider a case where you are providing a questionnaire to the users. Visually, the questionnaire looks like this:
These are the features of this component:
- Display query/question
- Options from which a user may choose to select one or more options
- A “skip for now” option if the user is not interested in responding to any particular prompt
We’ll call this component the Multi-select component. Now you may decide to turn this entire component into a single file, or you may want to break it into multiple small units. The above component can be broken into:
- A question section
- An options section
- A skip section
Can we further split these units into smaller units (and more importantly is this even necessary)? While the Question and Skip sections seem to be small enough since they have a single concern each, the Options section still has multiple concerns.
Breaking down the options section
Right now this component has two concerns:
- Render the list of options
- Handle the selection of each of these options
We can break the component into smaller units by separating out or delegating the concern to independent components. So the smaller units that can be created by breaking the options section would be:
- Option component
This is concerned with rendering an actual component and providing API that supports selection/de-selection of option as well as showing the current state of the component - OptionList component
This renders the list of options only. Invoking an Option component for each option that needs to be displayed to the user and provides the relevant data/functions needed for the option component
You may be wondering why we need to break the options section down further and perhaps deem this unnecessary. One of the answers to this question is “unit testing”.
If you were to perform unit testing for the options section then you won’t be able to test certain behavior which will be private to the component; for example, the selection of an option. Changing the API of your components to support unit testing is an anti-pattern and is not recommended. Whereas — by breaking the options section into an option and optionlist — we have a component that provides API on an option level.
Conclusion
Writing unit test cases is not always possible and it's not a one-off task. If you write unit test cases you also need to maintain them; depending on how much tech bandwidth you have and what your priorities are as a team and organization.
Even if you don’t have time to write test cases, or have not yet started writing them, if you consider the case “what if I have to write test case?” while deciding the architecture of your application/feature (and especially at the implementation phase) it’ll help you in breaking your code into smaller units which are prerequisites for effective unit test cases.
