3 ms·
> The rationale being that until the API is fixed, I don't want to have to adapt the tests to the changing API all the time. The rationale behind test-first is
by naasking 4y ago
> The rationale being that until the API is fixed, I don't want to have to adapt the tests to the changing API all the time.
The rationale behind test-first is that you won't know what the API should look like until you try writing some sample client code that uses your provisional API to access some data. So why not make those tests, iron out the kinks in your API and have a few functional tests at the end of it; two birds, one stone.
- aatd86 4y agoStill makes more sense to go API first then unit tests rather than the reverse to me. Since an API is a composition of multiple parts that can be tested (the unit in unit testing), it only makes sense to create these tests once the relations between these parts/units are well-established. That doesn't have to always be after the API is completely done of course. Some internal functionalities are likely to be immutable. They can be tested quite early in the iteration timeline.
- naasking 4y agoWe're not really talking about unit tests though, we're talking test-first. They don't have to be unit tests, which is why I described writing sample client code because that's what you need to do to anyway to design your API.
- aatd86 4y agoHum... Usually TDD is associated with unit tests and the article even mentions "unit tests" in its title... What you describe however seems closer to integration/system testing which is one approach I and other people in this thread also tend to favor. But I've been writing UI code predominantly so I am biased here as unit testing has lower value.