Decoupling tests from implementation details
One of the goals of automated testing is to support refactoring, but many times, they get in the way. Tests should aim to define what is intended (behavior), not how it’s implemented (details).
Refactoring is a continuous task, so we should reduce the exposure to details. Also, tests should not hold us back when evolving the architecture. A good test suite enables coding to be fun.
Write your tests in such a way that as many implementation details as possible could be changed before a change to the test code itself is required. Object Design Style Guide
📝 I’ll split tests using the Arrange/Act/Assert terms (the same as Given-When-Then). This is one of the testing patterns that I adhere to and highly recommend.
Don’t change code for the sake of testing
Changing implementation code to please tests is the quickest way to couple your tests to the implementation. It’s a testing antipattern — check “Changing implementation to make tests possible”.
Test only using APIs
I don’t like the rule “test all classes, functions, and methods”. Instead, you should…
