Test public API, not implementation details
Consider the following little code snippet:
What is public API?
First of all, make yourself aware of what methods of your Auth class are meant to be accessible and visible to the user of the class. That’s the public API. In this case the only method that is supposed to be visible is:
boolean function login(username:String, password:String)
What are implementation details?
Tip: A user of your class Auth only cares about public API because that’s the only API that is well documented and maintained. So let’s make sure that this API works as expected and only test login. Applying this approach keeps the amount of tests as small as possible but effective as necessary.
A bad test
Testing Terminology: A test that fails, although the code changes shouldn’t have affected the test are often called: Fragile Test
Focus on simplicity, correctness and shortness of tests. You and your co-workers will enjoy the readability. Internal documentation meant for developers can be replaced by your tests. From now on your tests are the spec. What about refactoring? Super easy. Let’s say you replace _isEmpty for internal reasons by underscrore.isEmpty() and some days later by lodash.isEmpty(). No problem, you don’t even need to touch the tests. Just execute them and give yourself the confidence that login still works as expected. This process doesn’t only make refactoring easy, it encourages you to make your code continually better and let you react fast on internal design decisions. Code-reviews of refactoring steps can happen faster because one thing is sure, whatever your code does, it doesn’t break the public API because you didn’t touch the tests.
KISS! Testing less but the right things improves your development process and makes you and your co-workers happy. Implementation details are never mentioned within the spec, so they never appear within your tests.
Testing implementation details
- makes refactoring hard
- increases the cost of test maintenance
- does not improve the API
- slows down development process
- a waste of time
Testing public API
- improves readability of tests
- your tests are the specification
- less but better tests
- refactor fast without touching tests
- faster code review