It is thought this is like engineering. You design an experiment and then pass it. However, that is not how experiments work. You design an experiment, and then you collect results from it. These may be enough to indicate that you are doing something right/wrong. They are intended, though, to be directional learnings. Not decisions in and of themselves.
So, I probably described something in more of a strawman fashion than I had meant. I don't think that really changes my thoughts here, though.
(This all depends on having a clear enough idea of what the library needs to do that I can write realistic test code...I've also had the experience where I write the tests, write the library, and then find that the real system has a "hidden" requirement that isn't captured by the tests and requires a very different way of interacting with the library.)
To me, a test is not real client code. Real client code is code that calls the API in service of the user. E.g. the real client code for the Twitter API is in your preferred Twitter client, not in the tests that run against the Twitter API.
But yes, if the tests are well-designed and built with actual real-world experience, I do treat them like real client code. Someone looking to use the library should be able to read the unit tests and have a pretty good idea what code they need to write and what pitfalls they'll encounter. And when the library is redesigned or refactored, the tests are first-class citizens; they aren't mindlessly updated to fit the new code, they're considered alongside other client code as something that may or may not have to change but ideally wouldn't.
But note, in that world, you aren't necessarily building tests of your software. You are building specifications for your API. I can see how these might be seen as similar. And for large portions of your code, they can be.
However, for the vast majority of your code, it exists to help out other parts of your code. Not to be used as a library/framework by others.
You don't learn much the moment the test passes. But designing and writing the test requires understanding the requirements in detail, which is often a learning process.
This discussion on what happens - or doesn't happen - after the tests are passing is precisely the point of the article.
The idea of TDD is that every test you look at the existing code and improve it. The majority of developers I've seen trying TDD do this with small code but do not with significant codebases, and you end without the benefits.
Be ware, though, that you are not throwing your customers for a bad ride. As soon as you have customers, it is nigh impossible to throw away the code without neglecting them. And they are your ultimate responsibility. Not the code.
Sometimes the tests give you the starting point of the problem, "what is the simplest way to get result x" with a way to rapidly get feed back that all the requirements are ment as the structure takes form and you refactor all the code.
That's the only way I've ever heard it described. I thought that's why it's called "Test Driven"
If you read that as "write every single one of your tests, then write the code", then you see it as a strawman and not the point of TDD.
If you read that as "before you write any specific line of code, you write the test for it first", then you are likely to see that as the same as TDD.
I intended the second reading. I can see how both are accurate ways to read it, though. Apologies for the confusion.
Turns out we are all in agreement after all.
Writing tests before you work on the unit you're working on shouldn't be a problem because you should know what that unit is supposed to do. If you don't, then it doesn't matter if you do TDD, Agile, BDD, or whatever. You're not going to be able to do it right. Go have a conversation with someone to find out what that is supposed to do.
Not only this, but it's a blatant violation of TDD. TDD is having a single test go red->green, not a suite.
1. Write test; build fails because code under test DOESN'T EXIST
2. Write the least amount of code needed for the test to pass
3. Refactor & repeat process ad infinitum
The Wikipedia entry for TDD also states this explicitly [0]
This is a differentiating feature of test-driven development versus writing unit
tests after the code is written: it makes the developer focus on the requirements
before writing the code, a subtle but important difference.
That's interesting, because as a non-TDD practitioner who occasionally gets it evangelized to me, that's certainly how I was told to go about it by multiple people.
Possibly TDD has a marketing problem?
It does one requirement at a time. You might add a specification that the code has to create a list of strings from a data set. You write a test that takes a data set as input and checks the output to see if it is the expected result. This fails, because the code hasn't been written yet. Then you write the simplest function possible to make the test pass.
Once it passes, you check to see if anything can be refactored. You can refactor as much or as little as you like, provided that all the tests still pass. Once you're satisfied, you write another test for another requirement. It's like a spinning ratchet wheel, where the test suite is the pawl. It keeps you from backsliding, but you can't spin too fast, or it flies off and won't engage with the wheel. Turn-click-turn-click-turn-click.
Writing all your tests up front is one of the worst ideas I have ever heard.