The continued health of your software is important. With software testing in general, we focus on two types of testing:
- Unit Testing for testing each single component
- Integration Testing for testing of an entire system
While Integration Testing is focused primarily on detecting system-wide types of regressions, Unit Testing is focused on testing the smallest parts of our code.
Effective Unit Testing
Code is easier to create, maintain and change when we go about using Test Driven Design.
These mean creating tests based upon requirements (which will at first all fail), and then building out the code to fulfill these requirements (which should eventually all pass).
What we should test:
- Public Methods These are the exposed methods of your class, so these should be tested (with the exception being getters and setters. See below.).
What we should not test:
- Getters and Setters Typically getters and setters are a waste of time writing unit tests for. If there is some sort of complex logic within the methods, then these should get tested as well. Of course, my argument is that complex logic shouldn't even exist in these methods.
- Private Methods These can be tested via Reflection, but by testing private methods we eliminate the ability to refactor the inner workings of our object.
TDD vs BDD
So what are these acronyms for?
- TDD is "Test-Driven Development"
- BDD is "Behavior-Driven Development"
TDD is when we build tests that drive our software development process. We first create tests, we run these and watch them first fail. We then implement code to solve the issue. If the code solves the issue successfully, then the test will pass. The developer can continue to make modifications to the code going forward (refactoring, etc) and use the tests to validate that the software hasn't been broken.
When new features are added to the system, new tests are created and the process repeats itself.
BDD evolves from TDD and adds the concepts of readable and complete sentences so that someone can easily discern a business value from it.
It also integrates the concept of a user story, such as "As a [role] I want [feature] so that [benefit]". This is defined as the Given-When-Then (GWT) way to write down test cases. As an example: "Given [initial context], when [event occurs], then [ensure some outcomes]".
Examples in Different Languages
Check out the following posts that discuss various types of testing in different languages: