- TDD's main idea is simply start working working on code by writing automated tests BEFORE writing the code that is being tested.
- There are many test-running systems in Javascript: Jasmine, Jest, Tape, Mocha. They have their special features but the syntax is very similar.
- Writing tests is less about the syntax but more on the TDD philosophy, so I tried internalizing the concepts using Jest. Main goal is to know the why and what to test.
📌 Notes from The Magic of Testing
- Why most devs hate tests? They are slow and fragile and expensive (time).
- It is perfectly valid to delete some tests.
- Unit Test Goals: They must be thorough (we want them to prove logically and completely that the single object under test is behaving correctly) and stable (we dont want to break the test everytime the implementation detail is changed 😟), fast and few (write tests for the most parsimonious expression [mmmmmm 🤔]).
- The object under test have three origin of messages : Incoming - messages to the object from outside, Self - messages sent by the object under test to itself and Outgoing - messsages sent by the object to the outside.
- There are two types of messages : query and command. Queries return something or changes nothing. Command types return nothing but changes something.
- Grid of Test Rules
| Message Type | Query | Command |
|---|---|---|
| Incoming | Assert result Test incoming query messages by making assertions about what they send back. Test the interface and not the implementation. |
Test incoming command messages by making assertions about direct public side effects. DRY it out. Receiver of incoming message has sole responsibility for asserting the result of direct public side effects. |
| Sent to Self | Ignore: Do not test private methods. | Ignore: Do not test private methods. |
| Outgoing | Ignore. The receiver of an incoming query is solely responsible for assertions that involve state. If a message has no visible side effects, the sender should not test it |
Expect to send outgoing command messages using mocks |
- Do not test private methods. But break this rule if it saves money during development.
- A mock is a test double, it plays the role of some object in your real app. Ensure test double stays in sync with the API.
- Trust collaborators that they will do the right thing. Insist on simplicity.
- Getting better at testing takes time and practice.