Test Driven Development

>>60266194
>small project in TDD

The real payoff to TDD doesn't become really apparent until you're dealing with larger code bases.

It's a good way of making sure your code is doing what you think it is, and making sure the latest fix doesn't break anything else.

>>60266395
this. in my experience its not worth the time if its just a small project, but it really helps when theres a shit load of code and you want to make sure your changes didnt break anything

>>60266395
So you would not use it in lets say, custom CMSs, a 5k loc codebase?

File: 6jqju2dhpeky.jpg (359KB, 1639x2048px) Image search: [Google]

359KB, 1639x2048px

>>60266194
TDD is a meme invented for banks and shit.

Create Alg/Outline/Functionality
          /                \
         /                  \
    Code it           Code Tests
      ^  \                  /
      |    \               /
      |      \           /
      |      Compile
      |           |
       \--------Test
                  |
              Commit

>>60266435
Why not pick a language that requires less effort on testing. If your spending 75% of your time writing RoR tests then maybe you should have picked something that has compile-time errors.

>>60266549
Tests are there to catch logical errors, not compile time errors. If you're using a language that doesn't even catch broken code that shouldn't compile or is UB then I suggest rethinking your choice of compiler.

>60266484
I can't give you a specific loc threshold, but I'd definitely feel like I was living dangerously having 5k and no tests.

Is TDD any more than realizing that unit tests are good?

>>60266857
It's basically unit testing everything and then writing code based off the tests.

>>60266857
TDD is writing the unit tests first, then writing code to satisfy the unit tests.

You use the unit tests to define the functionality and API of the code you're going to write, then you implement.

TDD is the ADHD of programming

>>60266904
TDD is a meme and it is basically lying to yourself.
If you have proper requirements you don't need TDD to figure out all the cases in advance.

And why do I say is it lying to oneself? Well because a programmer is the last person you want to test his own code.
A programmer will write a dumb 'test' that reflects the code he has written, because he does it with that builder mindset and cannot see beyond.
For testing you need proper dedicated testers, which have a destroyer mentality, and know all the pitfalls. Then and only then you will be producing useful tests that have value.
Also testers can be hired for a fraction of the cost of a programmer.

Forcing programmers to test their own code doesn't add quality and is a waste of time.

>>60266579
my language doesn't even need a compiler.

>>60266919
This, only people lack math knowledge,time mananger and capacity to write specs need TDD aka manchildren code monkeys.

>>60268665
>>60266919
>TDD not needed

If you only write 10 ten lines of code in a meme language, yeah.

>>60268738
t. Agile (((evangelist)))

>>60268521
Sorry for your interpreted loss.

>>60268810
xD

>>60266194
TDD only used in embedded and some sensitive infrastructure products

>>60266904
>TDD is writing the unit tests first, then writing code to satisfy the unit tests.
Incorrect.
TDD is
- write simplest test for simplest functionality that is not present in the code yet
- write simplest code possible to pass that test
- possibly refactor
- repeat

>>60268491
Bullshit.

TDD is about writing unit tests. And unit tests are much lower level of abstraction that you get with requirements. When you do TDD, you usually work with isolated classes or methods.

>>60272995
The problem I usually see, is that people have hard time imagining "simplest" addition to the code. Way too often, they skip "trivial" code or ignore use-cases that seem too simple.

File: tdd_flow.gif (13KB, 489x511px) Image search: [Google]

13KB, 489x511px

>>60266194

TDD is great. It enhances productivity and it's a really satisfying way to work. I also like the "seperations of concerns" thought: you make a clear distinction between the WHAT and the HOW. Also you have to test anyway, so why not putting it in your workflow?

I just love the "red/green/refactor" workflow, because in the first step you can think about "what should my programm actually do?"

Often this helps to get a more precise image, show some pitfalls/edge cases or helps to prevent some code smells or inconsistencies.


It's also super beneficial when you write something, ignore it for some months and then start working with it again, i.e. add new functionality. Because all your old test will immediately tell you if you broke something. They will also tell you what you broke and why.

And when you found a bug, you can simply adjust your tests and make shit working again.


TDD is not perfect, there can alway be something you didn't think of. But it's much better than writing things in a monolithic way, hiring testers, starting all over again, hire testers again, hunt down small bugs, test it again and so on..