Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Test-Driven Development Bypasses Your Brain

stoneship.org

Post reply on HN
Print view View original

51–60 of 67 posts

Re: Test-Driven Development Bypasses Your Brain

#51

Post by ajanuary »

karterk wrote: post #44

I find TDD to be useful in two cases: 1. When I already know what I'm doing and it's just a matter of coding what's already in my mind 2. When I'm writing in a dynamically typed language, it forces me to be not lazy and have adequate test coverage since I don't have compile time type safety I do less of TDD when dealing with a statically typed language and/or when I'm working in an exploratory mode. TDD doesn't help…

  1. When I already know what I'm doing and it's just a matter of coding what's already in my mind
A concept often used in TDD is spiking. If you don't know what you're doing, do a quick and dirty untested version until you do know what you're doing. Throw that code away and TDD it with your new found knowledge.

Re: Test-Driven Development Bypasses Your Brain

#54

Post by rdfi »

taligent wrote: post #11

TDD in theory is a great idea. In practice it is dreadful. Because what has happened is that the obsession with code coverage has meant that developers create a whole raft of tests that serve no real purpose. Which due to TDD then gets translated into unworkable, unwieldy spaghetti like mess of code. Throw in IOC and UI testing e.g. Cucumber and very quickly the simplest feature takes 5x as long to develop and is bor…

I would argue that this type of discourse is not useful. There people putting effort into properly assessing the usefulness of using tdd. Personal anecdotes are of little value. See http://blinkingcaret.wordpress.com/2012/10/02/tdd-bdd-add-ev...

Re: Test-Driven Development Bypasses Your Brain

#55

Post by xtracto »

anthonyb wrote: post #50
DanielBMarkham wrote: post #28

This sounds a bit like "we don't need no stinking testing", but I know the author is trying to hit at a deeper point. I only wish he had done better. One of the problems here is language: TDD as a general concept can cover everything from high-level behavioral testing to a method-by-method way to design your program. There's a big difference between those two! In general, of course, programming is balancing what the…

Good luck doing TDD with behavioral tests. Running (eg.) Selenium tests repeatedly is only going to slow you down.

Tell me about it! I am in a project right now where we are required to run BDD tests (Cucumber) which hit real servers (no, mocks won't do it). Worse thing is, the 3rd party "ESB" we are using takes forever to shutdown and startup... and is being restarted a lot in the tests (someone else is doing the BDD tests as an "acceptance criteria").

The result? running the complete BDD test suite takes about 5 hours, which must be checked for every commit.

Re: Test-Driven Development Bypasses Your Brain

#56

Post by Throwadev »

taligent wrote: post #11

TDD in theory is a great idea. In practice it is dreadful. Because what has happened is that the obsession with code coverage has meant that developers create a whole raft of tests that serve no real purpose. Which due to TDD then gets translated into unworkable, unwieldy spaghetti like mess of code. Throw in IOC and UI testing e.g. Cucumber and very quickly the simplest feature takes 5x as long to develop and is bor…

Unit tests are still useful sometimes. Everyone, when they first start out, goes overboard with how many tests they write, and can't tell the difference between what should and shouldn't be tested. The first couple of projects that are unit tested for a developer tend to have so many tests that are brittle that it slows the entire process down.

What I do now is, well, I'm going to actually test stuff while I'm coding anyway right? Regardless if I'm doing TDD or not. Well unit tests give me a useful harness where I can write those tests, instead of hundreds of Console.WriteLines. It's basically not much more effort than Console.WriteLine() style "testing", except you are left with some reusable artifacts at the end that may come in handy later on.

Re: Test-Driven Development Bypasses Your Brain

#57

Post by sklivvz1971 »

pjmlp wrote: post #41
sklivvz1971 wrote: post #16

This article misunderstands TDD completely. In TDD, the tests are your specifications . Therefore, any code that passes the tests is formally correct - even though it should always be minimal (YAGNI). In fact, TDD is not simply "tests first". It is: write ONE test, make it pass with the MINIMUM amount of code, refactor, loop.

Usually this makes people go for very simple solutions without thinking properly what are the right data structures and algorithms for the problem at hand. I rather write proper designed code and write the tests afterwards, before delivering the code.

True, however the solution is ok since passing the test is the only quality you need.

If not, write a new test, make it pass. The naive implementation can be substituted with a different one easily since the tests guarantee correctness.

Generally though, since the "third leg" of TDD is refactoring, this ensures that the proper structures are going to be used in place as soon as they are actually needed.

Re: Test-Driven Development Bypasses Your Brain

#58

Post by typicalbender »

MattBearman wrote: post #9

Personally I completely disagree with this, I've never found myself randomly changing code in a desperate attempt to get a test to pass. Maybe it's because I'd been coding for years before I ever tried TDD, but when a test fails, I logically debug the code the same way I would if I wasn't using TDD. As far as I'm concerned having tests just flags possible errors much quicker, and also gives me more piece of mind that…

I also disagree with this article. I think the point of TDD is not to blindly mash at the keyboard to make tests to pass and TDD encourages you to go back and refactor code and tests after you get it passing. TDD gives you confidence that the functionality you developed yesterday doesn't break when you add more functionality today.

TDD isn't a be all and end all, its just one more tool in a developers toolbox that allows us to be better at your job. If you solely rely on TDD or [Insert newest popular development technique] you are going to have a bad time.

One place that I've found TDD to be insanely helpful is exposing the interaction between pieces of the system before building it out in code. I tend to write my tests from the bottom up, i write the assertion first, and then build up the stuff i need to test that assertion. This makes it easier to see whats needed to test the functionality and whether or not the test looks good or not.

Gary Bernhardt does a really good job at explaining his philosophy on TDD, which I really agree with, http://destroyallsoftware.com

Re: Test-Driven Development Bypasses Your Brain

#59

Post by Kequc »

xtracto wrote: post #55
anthonyb wrote: post #50

Earlier quoted context omitted.

Good luck doing TDD with behavioral tests. Running (eg.) Selenium tests repeatedly is only going to slow you down.

Tell me about it! I am in a project right now where we are required to run BDD tests (Cucumber) which hit real servers (no, mocks won't do it). Worse thing is, the 3rd party "ESB" we are using takes forever to shutdown and startup... and is being restarted a lot in the tests (someone else is doing the BDD tests as an "acceptance criteria"). The result? running the complete BDD test suite takes about 5 hours, which mu…

This doesn't sound very brain or productivity healthy.

Re: Test-Driven Development Bypasses Your Brain

#60

Post by nahname »

taligent wrote: post #11

TDD in theory is a great idea. In practice it is dreadful. Because what has happened is that the obsession with code coverage has meant that developers create a whole raft of tests that serve no real purpose. Which due to TDD then gets translated into unworkable, unwieldy spaghetti like mess of code. Throw in IOC and UI testing e.g. Cucumber and very quickly the simplest feature takes 5x as long to develop and is bor…

The thing about practice is that it takes practice. Here are the issues you raised:

- Focus on code coverage

- Testing nothing

- Spagetti code from doing TDD

- IOC + UI/Cucumber takes long to write and run

I would have to say I agree, there is a better way to do this. My guess from your last statement is that you are relatively new to software. Don't mistake your teams poor practices for the practices not working. Try to promote better practices.

Tell your team code coverage only informs you on what isn't being tested. It doesn't help with quality.

Tests, like code, should be deleted if they don't do anything. Strictly adhere to YAGNI,

If TDD is producing spagetti code, you are doing something very wrong in your tests. The tests should be short and focused, just like your code base. Those tests are hard to write on a messy code base, which forces you to refactor, which leads to clean code. Maybe read up on the SOLID principles and other code quality practices to see what you are missing. Refactoring techniques can be very helpful too. This takes years to get good at.

Cucumber is over used. Read about the testing triangle (http://jonkruger.com/blog/2010/02/08/the-automated-testing-t...). My guess is that your team is focusing on the top levels. Those tests provide little long term value, fail without good explanations and can be complicated to write and maintain.

Post reply on HN