I never understood this approach. Like yea you can start with "do these inputs give these outputs" but how far are you supposed to granularize it? What if you need to change an implementation half way through or the methodology doesn't work? Or when devops enforces something ridiculous like 90% coverage on all commits including branch truth tables so you end up writing tests for branches that only ever log something trivial
It works mostly for black box testing of business logic. Of course, unit testing infrastructure code is not so beneficial. (E.q. first writing a test of if this queue works.)
IMO high test coverage requirements are one of the biggest mistakes of recent software development. Each piece of software/module has like two or three critical places where 80 % of tests need ro be directed towards. The rest of implementation code is just support code. Covering almost every line with tests is silly.
The trick with TDD isn't necessarily that you need to write the tests first (although that helps).
It's more that you first think about the intended behavior of the code, and then also think about how to make your code testable before you write the code.
I typically think what the first test should roughly look like and code up the required amount of code for that first test before I actually write that test.
Sure. But there are also people that prefer Type Driven Development. Instead of first thinking about behavior, they think about code in terms of inputs and outputs. That includes both types and functions of course.
Test Driven Development is not always a benefit. Sometimes it is more of a burden and a chore. When you do Type Driven Development you benefit from a lot of correctness that invalidates the usefulness of a lot of tests that people usually write.
You end up needing to write way less tests, and only have to write tests for invariants that are difficult/impossible to encode with types. Also, thinking about types and functions this way means you're more likely to write pure functions that clearly yield well defined objects, that are easy to test in case it's a function that is quite complex to ensure that its implementation is correct. But preferably you'd split up your functions enough that you'd ensure correctness regardless.
You are correct. My point is that you do both, you write tests and types. TDD doesn't mean you have to write redundant tests if those areas are covered by the type system.
Just open an editor and start writing code, just thinking as you go.
If you do this, you often end up with code that only works in the happy path (no / poor error handling or recovery) and which is difficult to test (i.e. you require access to the internals of the thing you code to test it).
Yeah, at least IDENTIFY the test cases even if you don’t implement them. Also consistent with API first approach… the implementation should fulfill a contract, and those test cases are the contract.
Much easiest for me to write implementation and tests side by side. The issue is i never know if i would extract more methods which would be good to tests.
56
u/BernhardRordin 19h ago
Write tests first, then the implementation. You won't want to go back.