9 ms·

TDD can be great if you know exactly what you're building and what you must test for, but it gets in the way when you're rapidly prototyping and exploring. Jus

TDD can be great if you know exactly what you're building and what you must test for, but it gets in the way when you're rapidly prototyping and exploring. Just don't be dogmatic about practices like TDD. It's always a tradeoff. Being a good engineer means understanding when the tradeoff is worth it and when it isn't. Be wary of development teams, or people, that force you to practice certain methodologies regardless of context.

wpietri 4y ago
I think it depends on what you're exploring, honestly. TDD comes out of the same circles as Extreme Programming, aka XP. In XP, there's something known as a spike, which is basically a short-lived technical prototype. If you really don't know how to tackle something, you build a quick one to throw away. In that case, yes, definitely don't do TDD, because a goal of TDD is to build up a good test suite for production code. It's not a good match for throwaway code (assuming the team really has the discipline to throw it away.) But if I'm exploring in a way that feels less disposable to me, which happens often, then I'm happy to use TDD. E.g., if I want to try out a new way of solving a problem, or I have an idea for an architectural improvement. Then I'll use TDD to force myself to think about it from the outside in, to keep design considerations to the forefront.
LAC-Tech 4y ago
TDD can be great if you know exactly what you're building and what you must test for But you should know this from your functional requirements, right? (Slightly sarcastic comment, I know in a lot of places people just start coding without a plan, but I think TDD and functional requirements go together well).
- devoutsalsa 4y ago
  TDD is pretty useless when the requirements are shit. It just takes longer to realize you need better directions.
  - scott_w 4y ago
    Or it tells you straight away that you have no idea what you’re supposed to be doing instead of spending 3 days building the wrong thing.
- chrisandchris 4y ago
  > ... start coding without a plan ... Well, I don't do that. But i usually don't know all the names of my (internal) interfaces and models and properties right at the start. I might move things around and rename stuff along the way. And I think that's quite normal if you don't live in a world where the spec for a small task is multiple books thick. Doesn't TDD get in the way with? Wouldn't I keep refactoring the tests all the time then?
  - missingdays 4y ago
    When you rename an interface or a method, IDE renames them in tests too
- dmitriid 4y ago
  > But you should know this from your functional requirements, right? Functional requirements describe observable behaviour. You can't write any meaningful tests for that behaviour until a lot of your code is written. Yet somehow in all the discussions there's this unexplaned leap from "you have the requirements" -> "well you just write a unit test for your function first, and then code it". My functional requirements come in the form of "Given publisher A in Country B and contract requirements C the service must return D for a subset of products E", for multiple combinations of A, B, C, D, and E. And where each of those may and will require lookups in external services and databases.
cratermoon 4y ago
Here's the thing. When I'm rapidly prototyping and exploring, I'm constantly asking questions and making hypotheses about what the thing I'm exploring will do when I turn various knobs and pull different levers. Part of any good process of making guesses and comparing the expected and actual results is making notes about the test and results. Those notes could be written in natural language, and many notes should start there, but why not formalize the guesses and discoveries and write them as executable, reproducible, tests?
LouisSayers 4y ago
Agreed. Essentially if you don't have an existing code structure in place, TDD will be very confusing and you'll end up tangling yourself into a coding mess. On the contrary, if you have a structure in place and need to ensure the correctness of the code you're about to write, it is incredibly useful. Building my own stuff, I hardly ever write any tests tho as in the early stages of a project, testing will slow you down as the tests are essentially locking your code in. For me personally, I prefer to have my code be more fluid so I can rapidly change it without having the overhead of having to write and rewrite the corresponding tests. When I come across some tricky logic tho I will definitely crank out some tests as it actually helps to create the solution. As usual context is key to knowing whether TDD (or even testing) is appropriate or not.
lnxg33k1 4y ago
Not really, TDD helps you to think about what you're writing and even when you're prototyping from scratch gives you a good overview of the complexity of what you are writing, because you can't just finish a method that is few tens of lines long then try to test it, you write small test case, then you evolve the method that is being tested by the unit test and so on, and you can see when it's becoming too complex, I think some people just is not used to small methods whose responsibilities are well thought beforehand and just try to be a cowboy, TDD is about the quality of the code, the clarity of code, mantainability of code, as unit test, not necessarily the correctness of code in production
lukashrb 4y ago
> but it gets in the way when you're rapidly prototyping and exploring. If you prototype a new features for an existing system, a test let you execute only the code you actually need. This will shorten your feedback loop and allow you to iterate faster. Refactoring a test is fine. Writing a BS test just to explore a solution is fine. In my experience following a test lead practice will help you build a simpler system which will be easier to maintain.
- wmwragg 4y ago
  I tend to view TDD as a form of coding using a REPL, like in Lisp, where you can easily test chunks of your code as you go along. The main difference is that you leave behind your tests so they can be used in the future.
onion2k 4y ago
TDD can be great if you know exactly what you're building and what you must test for, but it gets in the way when you're rapidly prototyping and exploring. It sounds like you're making the mistake of thinking that TDD means writing the tests first. That's not quite right but it's understandable that lots of people believe it given the way TDD is usually discussed. In TDD you should be writing one test first. Then you write enough code to make that test pass. Then add a second test. Get that to pass. And so on. If you realise you missed something you can delete tests that don't make sense any morejuat like you delete code that doesn't make sense. In essence TDD is about writing the tests in parallel to writing the code instead of writing them afterwards. You can easily prototype and experiment with TDD because you're never much further ahead with your tests. TDD is faster than writing tests later because your code has to be testable throughout the process. Writing tests later often means you need to refactor or rebuild to make it testable, which is a waste of effort, even in a prototype.
- rolisz 4y ago
  But what test do I write? What does the poorly documented 3rd party API return? Is the test failing because there's an edge case in the API or because my code is wrong?
  - sbysb 4y ago
    The very first test can be a simple "Did my HTTP request receive a response?". Then you can build on "Does this HTTP response have this value I need".... etc The way I have always gone about TDD is just that I am testing the code I am writing by running the test, not from the main entrypoint of the application. The things you would log and look for when you run the application you instead validate with an `assert()`. Then once you have finished developing, you do a single pass verification from main and you have both a test and a function written
    - lcw 4y ago
      Do you see how playing this game of writing iterative tests would actually provude slower learnings than prototyping a call to an API and receiving a result that would inform a series of tests that would be much more informed? It's just as easy to be inefficient writing useless/bad tests than it is writing bad code. I think every developer should do TDD in their career, because it will make you think about the testability of the code. That said once you understand how to write testable code than I think it makes sense to be flexible on whether you write the test first or take a crack at an implementation. The argument that you should have a good understanding of requirements I think leads to a lot of analysis paralysis, and isn't a practical method for building novel things in a timely manner.
randomdata 4y ago
I disagree. TDD shines most when you don't know what you are building. It allows you to to test hypotheses without needing to over-implement a system to be able to begin to gather data about your design. In fact, if you know exactly what you are building, how could tests drive your decisions? You have already made up your mind. If you know what you are building you can simply implement it straight away without the data gathering phase.
ChrisMarshallNY 4y ago
> if you know exactly what you're building and what you must test for This is the main issue that I have with TDD. I use a methodology that I call "Evolutionary Design,"[0] and TDD won't work for that. But I think they have the right idea, in emphasizing the need for extreme Quality. I like to achieve this, by using test harnesses, as opposed to unit tests[1]. [0] https://littlegreenviper.com/various/evolutionary-design-specification/ https://littlegreenviper.com/various/evolutionary-design-spe... [1] https://littlegreenviper.com/various/testing-harness-vs-unit/ https://littlegreenviper.com/various/testing-harness-vs-unit...
deterministic 4y ago
Eh? You can’t prototype or explore if you have no idea what you are building. You obviously have some idea (3rd person shooter or accounting system?) but might not be sure how to organize your code. However well written tests are independent of how you organize your code or any other implementation details. So tests are great even when you are just prototyping or exploring. You can rapidly change your code and have the tests ensure that it still works the same way. And the end result is a fully tested, easy to maintain code base. What’s not to love about that?

wpietri 4y ago

I think it depends on what you're exploring, honestly. TDD comes out of the same circles as Extreme Programming, aka XP. In XP, there's something known as a spike, which is basically a short-lived technical prototype. If you really don't know how to tackle something, you build a quick one to throw away. In that case, yes, definitely don't do TDD, because a goal of TDD is to build up a good test suite for production code. It's not a good match for throwaway code (assuming the team really has the discipline to throw it away.) But if I'm exploring in a way that feels less disposable to me, which happens often, then I'm happy to use TDD. E.g., if I want to try out a new way of solving a problem, or I have an idea for an architectural improvement. Then I'll use TDD to force myself to think about it from the outside in, to keep design considerations to the forefront.

LAC-Tech 4y ago

TDD can be great if you know exactly what you're building and what you must test for But you should know this from your functional requirements, right? (Slightly sarcastic comment, I know in a lot of places people just start coding without a plan, but I think TDD and functional requirements go together well).

devoutsalsa 4y ago
TDD is pretty useless when the requirements are shit. It just takes longer to realize you need better directions.
- scott_w 4y ago
  Or it tells you straight away that you have no idea what you’re supposed to be doing instead of spending 3 days building the wrong thing.
chrisandchris 4y ago
> ... start coding without a plan ... Well, I don't do that. But i usually don't know all the names of my (internal) interfaces and models and properties right at the start. I might move things around and rename stuff along the way. And I think that's quite normal if you don't live in a world where the spec for a small task is multiple books thick. Doesn't TDD get in the way with? Wouldn't I keep refactoring the tests all the time then?
- missingdays 4y ago
  When you rename an interface or a method, IDE renames them in tests too
dmitriid 4y ago
> But you should know this from your functional requirements, right? Functional requirements describe observable behaviour. You can't write any meaningful tests for that behaviour until a lot of your code is written. Yet somehow in all the discussions there's this unexplaned leap from "you have the requirements" -> "well you just write a unit test for your function first, and then code it". My functional requirements come in the form of "Given publisher A in Country B and contract requirements C the service must return D for a subset of products E", for multiple combinations of A, B, C, D, and E. And where each of those may and will require lookups in external services and databases.

cratermoon 4y ago

Here's the thing. When I'm rapidly prototyping and exploring, I'm constantly asking questions and making hypotheses about what the thing I'm exploring will do when I turn various knobs and pull different levers. Part of any good process of making guesses and comparing the expected and actual results is making notes about the test and results. Those notes could be written in natural language, and many notes should start there, but why not formalize the guesses and discoveries and write them as executable, reproducible, tests?

LouisSayers 4y ago

Agreed. Essentially if you don't have an existing code structure in place, TDD will be very confusing and you'll end up tangling yourself into a coding mess. On the contrary, if you have a structure in place and need to ensure the correctness of the code you're about to write, it is incredibly useful. Building my own stuff, I hardly ever write any tests tho as in the early stages of a project, testing will slow you down as the tests are essentially locking your code in. For me personally, I prefer to have my code be more fluid so I can rapidly change it without having the overhead of having to write and rewrite the corresponding tests. When I come across some tricky logic tho I will definitely crank out some tests as it actually helps to create the solution. As usual context is key to knowing whether TDD (or even testing) is appropriate or not.

lnxg33k1 4y ago

Not really, TDD helps you to think about what you're writing and even when you're prototyping from scratch gives you a good overview of the complexity of what you are writing, because you can't just finish a method that is few tens of lines long then try to test it, you write small test case, then you evolve the method that is being tested by the unit test and so on, and you can see when it's becoming too complex, I think some people just is not used to small methods whose responsibilities are well thought beforehand and just try to be a cowboy, TDD is about the quality of the code, the clarity of code, mantainability of code, as unit test, not necessarily the correctness of code in production

lukashrb 4y ago

> but it gets in the way when you're rapidly prototyping and exploring. If you prototype a new features for an existing system, a test let you execute only the code you actually need. This will shorten your feedback loop and allow you to iterate faster. Refactoring a test is fine. Writing a BS test just to explore a solution is fine. In my experience following a test lead practice will help you build a simpler system which will be easier to maintain.

wmwragg 4y ago
I tend to view TDD as a form of coding using a REPL, like in Lisp, where you can easily test chunks of your code as you go along. The main difference is that you leave behind your tests so they can be used in the future.

onion2k 4y ago

TDD can be great if you know exactly what you're building and what you must test for, but it gets in the way when you're rapidly prototyping and exploring. It sounds like you're making the mistake of thinking that TDD means writing the tests first. That's not quite right but it's understandable that lots of people believe it given the way TDD is usually discussed. In TDD you should be writing one test first. Then you write enough code to make that test pass. Then add a second test. Get that to pass. And so on. If you realise you missed something you can delete tests that don't make sense any morejuat like you delete code that doesn't make sense. In essence TDD is about writing the tests in parallel to writing the code instead of writing them afterwards. You can easily prototype and experiment with TDD because you're never much further ahead with your tests. TDD is faster than writing tests later because your code has to be testable throughout the process. Writing tests later often means you need to refactor or rebuild to make it testable, which is a waste of effort, even in a prototype.

rolisz 4y ago
But what test do I write? What does the poorly documented 3rd party API return? Is the test failing because there's an edge case in the API or because my code is wrong?
- sbysb 4y ago
  The very first test can be a simple "Did my HTTP request receive a response?". Then you can build on "Does this HTTP response have this value I need".... etc The way I have always gone about TDD is just that I am testing the code I am writing by running the test, not from the main entrypoint of the application. The things you would log and look for when you run the application you instead validate with an `assert()`. Then once you have finished developing, you do a single pass verification from main and you have both a test and a function written
  - lcw 4y ago
    Do you see how playing this game of writing iterative tests would actually provude slower learnings than prototyping a call to an API and receiving a result that would inform a series of tests that would be much more informed? It's just as easy to be inefficient writing useless/bad tests than it is writing bad code. I think every developer should do TDD in their career, because it will make you think about the testability of the code. That said once you understand how to write testable code than I think it makes sense to be flexible on whether you write the test first or take a crack at an implementation. The argument that you should have a good understanding of requirements I think leads to a lot of analysis paralysis, and isn't a practical method for building novel things in a timely manner.

randomdata 4y ago

I disagree. TDD shines most when you don't know what you are building. It allows you to to test hypotheses without needing to over-implement a system to be able to begin to gather data about your design. In fact, if you know exactly what you are building, how could tests drive your decisions? You have already made up your mind. If you know what you are building you can simply implement it straight away without the data gathering phase.

ChrisMarshallNY 4y ago

> if you know exactly what you're building and what you must test for This is the main issue that I have with TDD. I use a methodology that I call "Evolutionary Design,"[0] and TDD won't work for that. But I think they have the right idea, in emphasizing the need for extreme Quality. I like to achieve this, by using test harnesses, as opposed to unit tests[1]. [0] https://littlegreenviper.com/various/evolutionary-design-specification/ https://littlegreenviper.com/various/evolutionary-design-spe... [1] https://littlegreenviper.com/various/testing-harness-vs-unit/ https://littlegreenviper.com/various/testing-harness-vs-unit...

deterministic 4y ago

Eh? You can’t prototype or explore if you have no idea what you are building. You obviously have some idea (3rd person shooter or accounting system?) but might not be sure how to organize your code. However well written tests are independent of how you organize your code or any other implementation details. So tests are great even when you are just prototyping or exploring. You can rapidly change your code and have the tests ensure that it still works the same way. And the end result is a fully tested, easy to maintain code base. What’s not to love about that?