Gregory's ServerThe problem with Test-Driven Development is that you have to think about what you want the code to do before you write it. And that ruins the surprise.
 47 comments
@deirdresm I've found that the discovery often comes after we've shipped working code π @jadonn @jasongorman @deirdresm There has been at least one occasion where a "bug" we've introduced was actually a better response to a sequence of events, better at meeting the spirit of the requirement, than the actual design. That wouldn't have been realised in a pure TDD. I immediately thought of the filk song of that name (written by Leslie Fish, but this is the best performance) about Sputnik having beat the US into space:  @jasongorman π€ Howdy, TDD. This city isn't big enough for cowboy coding and you. See you at high noon. End of the story: The revolver wasn't tested and didn't work as expected. The cowboy lost. @jasongorman Iβve found that when working in languages with very expressive type systems, writing the types themselves also plays this role a bit. @jasongorman For me, itβs just like what you said about how tests force you to think carefully about behavior before you write the code. In the case of writing expressive model types, youβre forced to think carefully about the concepts/entities youβre trying to represent. @jasongorman For me, getting the model types right makes it easier to think through the behavior properly. The simplest example is nullability. If your type system can express that and enforce null handling, then that forces you to think about stuff like βhow should this operation behave when property A is nullβ? Iβd say sum types (e.g. sealed classes) where the compiler can check that youβve exhaustively handled all scenarios is the next level of that beyond nullability. @jjoelson @jasongorman Or even better, replace nullability with Optional types and the API itself forces you to deal with those cases, you don't need a fancy schmancy null-checking systems π @jasongorman This is like asking a TDD practitioner βhow do you know what tests to write?β and the answer is the same. @jjoelson We write tests for end user outcomes. How do you know what types the model needs? @jasongorman By the same token, how do you write tests if there are no types defined anywhere? @jasongorman My original point is writing model types can sit alongside writing tests as an activity that clarifies what your system actually *is* and *does*. It sounds like you prefer to think in terms of *behaviors*, hence your focus on tests as the starting point. For me, modeling the problem data domain is a more helpful starting point because itβs difficult for me to think about overall system behaviors in such an abstract way without having types to organize and guide. @jasongorman This is interesting, because you seem to agree that writing the types and method signatures is a necessary prerequisite to writing complete tests, but of course if you stopped after writing the types and never actually finished the tests then youβve already done a chunk of the thinking about the systemβs behavior. My original point is that the more expressive the type system, the more youβve achieved in terms of understanding what your code will do just by writing the types. @jjoelson In TDD, we work backwards from the test code. It tells us what types and methods we need, and we declare those types *only* when a failing test requires it. We don't write a single line of source code that isn't required for the test. The tests drive the design. The clue's in the name, really π  @jasongorman @jjoelson @jjoelson @jasongorman IME that has as much of the discovery / improvisation aspect as shell pipelines @jasongorman @jjoelson @jasongorman I know it seems like it spoils it, but in my experience, the real joy is discovering, 3 years later, how the code really does it.  @jasongorman if you don't have requirements, your code can't be wrong...it can only be surprising.  @jasongorman @danielcornell Decades ago, my dad used to write his entire program in his head before he went to the keyboard to type it all in. π€·π»ββοΈ  @jasongorman instead of writing tests first i prefer implementing feature in a way that it can be easy testable and then write the tests. Is this TDD as well? π  @jasongorman tdd can work well if you have a good idea what you want. I personally like scaffold testing. You build the thing, create a test that's good enough, then move on. Then create some really good integration tests. Works out well in older systems that have very little or no testing. @jasongorman @Gargron maybe if you des rive the test in ChatGPT prompt and ask for the code that would pas that test ? @Vive_Levant @Gargron Tried that. Tried every which way. Me driving. It driving. Test-first. Test-after. @jasongorman also, users are infinitely more creative at finding bugs and holes than test cases can ever be. @damienhurrell @jasongorman |
@jasongorman As a discovery writer, this is one reason I dislike a pure TDD approach.