Well so before you code it you still have an idea of what you want the program to do, right? So you write a test for the program to pass or fail based on that idea of functionality, and then you write the program to pass the test.
So for something simple like programming a calculator you might write test code that verifies whether your addition function properly adds two numbers together then write the actual addition function.
Later on as you continue to build the program your addition test will still be out there verifying that you haven’t broken anything with subsequent code.
Some people will tell you that TDD tends to work better with established codebases in corporate environments where you have huge interrelated programs and maybe hundreds or even thousands of developers working concurrently as opposed to simple projects or startups where you might want to prioritize having a product set out before you start to implement rigorous testing requirements.
A lot of people don’t like TDD because they see it as extra overhead and don’t want to spend time writing test code when they could be writing “real code.”
Proponents of TDD tend to point to the fact that it contributes to stability in the overall codebase and allows you to quickly and easily find and diagnose problems, and it can make you a better developer to think ahead rather than just dumping code into the codebase and assuming it’s going to work.
Yeah, TDD is all fine and stuff until you have a system that communicates to a lot of other systems, and also has some weird dependencies, and since you are unit testing you need 300 foxtures and 100 mocks just to get the required coverage and then COVERAGE IS A FUCKING LIE.
The Test part of TDD isn’t meant to encompass your whole need before developing the application. It’s function-by function based. It also forces you to not have giant functions. Let’s say you’re making a compiler. First you need to parse text. Idk what language structure we are doing yet but first we need to tokenize our steam. You write a test that inputs hello world into your tokenizer then expects two tokens back. You start implementing your tokenizer. Repeat for parser. Then you realize you need to tokenize numbers too. So you go back and make a token test for numbers.
So you don’t need to make all the tests ahead of time. You just expand at the smallest test possible.
My friend, let me tell you a story during my studies when I had to help someone find a bug in their 1383-line long main() in C… on the other hand I think Ill spare you from the gruesome details, but it took me 30 hours.
Case in point, actually. Whenever I’m forced to write a giant function, I always get nervous because it could be crawling with bugs that I have little hope of spotting.
How would you know what you’re going to need or what it can do before you code it ?
There’s some things called software architecture, requirement engineering and software design. More dev teams should try this.
Well so before you code it you still have an idea of what you want the program to do, right? So you write a test for the program to pass or fail based on that idea of functionality, and then you write the program to pass the test.
So for something simple like programming a calculator you might write test code that verifies whether your addition function properly adds two numbers together then write the actual addition function.
Later on as you continue to build the program your addition test will still be out there verifying that you haven’t broken anything with subsequent code.
Some people will tell you that TDD tends to work better with established codebases in corporate environments where you have huge interrelated programs and maybe hundreds or even thousands of developers working concurrently as opposed to simple projects or startups where you might want to prioritize having a product set out before you start to implement rigorous testing requirements.
A lot of people don’t like TDD because they see it as extra overhead and don’t want to spend time writing test code when they could be writing “real code.”
Proponents of TDD tend to point to the fact that it contributes to stability in the overall codebase and allows you to quickly and easily find and diagnose problems, and it can make you a better developer to think ahead rather than just dumping code into the codebase and assuming it’s going to work.
Yeah, TDD is all fine and stuff until you have a system that communicates to a lot of other systems, and also has some weird dependencies, and since you are unit testing you need 300 foxtures and 100 mocks just to get the required coverage and then COVERAGE IS A FUCKING LIE.
You don’t write a whole app in tests and then write the whole app in code, you make tests for the functionality as you go.
The Test part of TDD isn’t meant to encompass your whole need before developing the application. It’s function-by function based. It also forces you to not have giant functions. Let’s say you’re making a compiler. First you need to parse text. Idk what language structure we are doing yet but first we need to tokenize our steam. You write a test that inputs
hello worldinto your tokenizer then expects two tokens back. You start implementing your tokenizer. Repeat for parser. Then you realize you need to tokenize numbers too. So you go back and make a token test for numbers.So you don’t need to make all the tests ahead of time. You just expand at the smallest test possible.
No, being unable to read giant functions is what forces me not to have giant functions.
My friend, let me tell you a story during my studies when I had to help someone find a bug in their 1383-line long main() in C… on the other hand I think Ill spare you from the gruesome details, but it took me 30 hours.
Case in point, actually. Whenever I’m forced to write a giant function, I always get nervous because it could be crawling with bugs that I have little hope of spotting.
I don’t know if you’re joking or not. I suppose tdd will help know what you need before you start.