If we want to change our code without worry about breaking anything, then having unit tests is important.
In this article, we’ll look at how to write unit tests so that we can have peace of mind when changing code.
Writing Unit Tests
Unit tests shouldn’t be in a far-away corner of the source tree. It should be conveniently located so that we can easily look for them and change them is necessary.
For small projects, we can embed the tests in the module itself.
For larger projects, we can move them into their own subdirectory.
By writing unit tests, we’re providing developers who look at our code with 2 invaluable resources.
They include examples of how to use the functionality of our module. And a means to build regression tests to validate future change of our code.
Therefore. it’s great for documentation of our code and also makes updating the tests later easier for everyone.
A unit test will call a function with an argument and check against the results returned.
We must run them often so we’re checking if our stuff is still working all the time.
Using Test Harnesses
Test harnesses are standard sets of data and code that we use to run our tests.
It’s used to handle common things like logging, analyzing expected results, and selecting and running tests.
Test runners probably have lots of these functionalities of already so we can just use them.
However, if they aren’t present in our testing framework, then we’ve to write them ourselves.
We can create a base class that provides these common operations. Individual tests can be a subclass of the hardness class so that we can just call the methods in the test class.
This is good because it meets the DRY principle. We aren’t repeating any code for logging and checking results.
A harness should provide a standard way of setting up our tests and cleaning up after it’s run.
It should have a method for selecting individual tests or all available tests.
Also, it should have a means of analyzing output from expected or unexpected results.
Failure reporting should also be standard in our test harness.
Tests should be composable. This means that a test can be composed of subtests of subcomponents of any depth.
We may add tests to help us debug our code. This may be a logging statement or a code that interacts with the IDE.
Once we’re done debugging, then we formalize the test. If we break it once then it’s likely to break again, so we should just add a test to make sure that it doesn’t break again.
Build a Test Window
We should test our software once it’s been deployed with real-world data flowing through it,
We can do that with our own end-to-end tests. There’re many ways to make our app run like how a user would have interacted with it.
First, we need clean seed data populated inside our app. Then we need to write tests with frameworks like Selenium to interact with our app like how users would have interacted with it.
Once we’re done with the tests, we reset the data to the original seed data so that our tests will run consistently.
A Culture of Testing
All software that we write will tested by someone including our test and users. Therefore, we should make sure that we have to test it thoroughly before we release it into any environment.
This minimizes maintenance costs and customer service calls.
Therefore, testing should be a habit. If we don’t test our stuff, then our users will.
Conclusion
We should have a culture of testing ingrained. Because if we don’t test our stuff thoroughly then our users will.
To make our lives easier, we should write unit tests and end to end tests.
This way, we can test everything automatically without thinking once the test is written.
Also. we should make sure that we use a test harness or write our own so that we can run our tests and log the results of the tests.
