Email or username:

Password:

Forgot your password?
Jason Gorman

The 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
Deirdre Saoirse Moen

@jasongorman As a discovery writer, this is one reason I dislike a pure TDD approach.

Jason Gorman

@deirdresm I've found that the discovery often comes after we've shipped working code πŸ™‚

jadonn

@jasongorman @deirdresm

Isn't there an old saying about how bugs are just the features you haven't met yet? πŸ™ƒ

Justin Skists

@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.

Deirdre Saoirse Moen

@AdeptVeritatis @jasongorman

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:

youtube.com/watch?v=K90tJ0xRWi

#Filk #Music

Johannes Link

@jasongorman TDD takes away dopamine release for some people.

Jason Gorman

@jlink They get it back from seeing green builds, though

Johannes Link

@jasongorman The green bar has a soothing effect. No dopamine in there for me.

Claudio Zizza 🦜

@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.

Jonathan Joelson

@jasongorman I’ve found that when working in languages with very expressive type systems, writing the types themselves also plays this role a bit.

Jason Gorman

@jjoelson I guess the question then is how do we know we need those types?

Jonathan Joelson

@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.

Jonathan Joelson

@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.

Jakub Neruda

@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 πŸ˜‰

Jason Gorman

@jjoelson But how do you know what types the model needs?

Jonathan Joelson

@jasongorman This is like asking a TDD practitioner β€œhow do you know what tests to write?” and the answer is the same.

Jason Gorman

@jjoelson We write tests for end user outcomes. How do you know what types the model needs?

Jonathan Joelson

@jasongorman By the same token, how do you write tests if there are no types defined anywhere?

Jonathan Joelson

@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.

Jason Gorman

@jjoelson You define them in the tests by their usage and work backwards πŸ™‚

Jonathan Joelson

@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.

Jason Gorman

@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 πŸ™‚

Wolf480pl replied to Jason

@jasongorman @jjoelson
can you, with clear conscience, press Ctrl+S ona file that doesn't typecheck?

Wolf480pl

@jjoelson @jasongorman
can't you just fire up a repl, and check the type of an expression, then keep adding more things to that expression, until you like the type, and only then copy it to the source file?

IME that has as much of the discovery / improvisation aspect as shell pipelines

Jason Gorman

@wolf480pl @jjoelson Where do users and their goals fit in to this approach?

Wolf480pl

@jasongorman @jjoelson
I'm starting to suspect your problem isn't caused by TDD, but by writing software for people other than yourself /hj

Eric's Edge

@jasongorman the surprise is experienced later when a real user takes over.

Tristan Colgate-McFarlane

@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.

noplasticshower

@jasongorman if you don't have requirements, your code can't be wrong...it can only be surprising.

Wendy Nather

@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. πŸ€·πŸ»β€β™€οΈ

Frank Kusel

@jasongorman That hurts, because it's true. πŸ˜‚

arek czogala

@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? πŸ˜‰

Not David Beckham

@jasongorman
Test in production. It increases the surprise

Michael Chrisco :rootaccess:

@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.

Vive_Levant

@jasongorman @Gargron maybe if you des rive the test in ChatGPT prompt and ask for the code that would pas that test ?

Jason Gorman

@Vive_Levant @Gargron Tried that. Tried every which way. Me driving. It driving. Test-first. Test-after.

Damien Hurrell

@jasongorman also, users are infinitely more creative at finding bugs and holes than test cases can ever be.

Rufus T Firefly

@damienhurrell @jasongorman
The most compelling reason TDD is that it documents the real behavior of the code. Super useful when refactoring.

Jason Gorman

@RTFirefly @damienhurrell And refactoring is super-useful when TDDing πŸ™‚

Go Up