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

Ask HN: Help me see why everyone seems to love TDD?

news.ycombinator.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Ask HN: Help me see why everyone seems to love TDD?

#81

Post by stevesun21 »

joshka wrote: post #30
stevesun21 wrote: post #24

my personal style to design a system is to focus on design the domain model, I believe that this is an intuitive way for people to design stuff (not just software, also in math and ML). This is the reason why I am not sold by TDD which start with writing test cases first – how come people can tell what is going to test before they know what they are going to develop. I tried some projects with TDD, but unfortunately,…

The last D is design... Write your test as if the perfect domain model existed already, and then make it work. E.g. does it make more sense to write person.Age = 21, or person.Birthday = someDate. Alternatively, taking your math example, your tests are the constraints of an equation that your code solves.

Based on what I learnt I am not really see the last D is design.

https://en.m.wikipedia.org/wiki/Test-driven_development

http://martinfowler.com/bliki/TestDrivenDevelopment.html

Re: Ask HN: Help me see why everyone seems to love TDD?

#82

Post by brianwawok »

marxama wrote: post #80
brianwawok wrote: post #77

Earlier quoted context omitted.

I have had people I trust a lot more than myself argue this. That humans are better exploratory testers than robots. Totally agree that humans doing manual regressions is bad. I would almost argue that needing humans to do regressions means that something is broke in your coding / testing / deployment process. If page X must REALLY do Y and always work, why aren't you testing it on 30 browsers automatically? Even a v…

One thing is that a lot of testers are still working in a very rigid way. First, design and write down the test cases (based on a specification that is most likely flawed and incomplete). Then, perform the tests. Then, document the results. There is very little room for creativity and exploration in such a process. This is basically what you do when you write automated tests, except the execution (and reporting) step…

Ya the embedded tester thing. I have never really done that, but I can totally see a lot of value.

I HAVE had places where the team lead didn't code and basically acted as the embedded QA. That isn't terrible.

Re: Ask HN: Help me see why everyone seems to love TDD?

#83

Post by collyw »

mbrock wrote: post #57
collyw wrote: post #54

Earlier quoted context omitted.

"If you want an agile unit test suite, it has to run in seconds, not minutes. TDD will make this very clear. If you have problems with the test suite being slow, you have to fix it!" To me this is TDD going putting the cart before the horse. Test driven design. Except you design so that the tests run fast. And the application design, is that actually considered?

Of course it's considered. It's not difficult to write fast unit tests if you follow the principles that make them fast. A fast test suite has lots of value, and doesn't conflict with good design—on the contrary.

The Rails guy wrote about this. http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv...

Re: Ask HN: Help me see why everyone seems to love TDD?

#84

Post by mbrock »

collyw wrote: post #83
mbrock wrote: post #57

Earlier quoted context omitted.

Of course it's considered. It's not difficult to write fast unit tests if you follow the principles that make them fast. A fast test suite has lots of value, and doesn't conflict with good design—on the contrary.

The Rails guy wrote about this. http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv...

I disagree with him but I'm also not a TDD fanatic in any way. Still, I find it useful to structure my code as units with few dependencies and minimal side effects, which makes unit testing a very appropriate methodology. I don't always do tests first, but I think as a methodology it's as reasonable as anything.

Re: Ask HN: Help me see why everyone seems to love TDD?

#85

Post by stestagg »

brianwawok wrote: post #64
dingaling wrote: post #35

Earlier quoted context omitted.

> Fire manual QA team and hire people to write automated integration tests. From experience, this leads to coders coding-to-the-tests. It compiles, it passes, ship it. Does it doing the right thing under stress? Who knows. Manual QA staff, proper QA staff, do crazy non-linear things that stresses code like customers do. I'll bet they would have caught that bug in the other front-page story about the animal feeders fa…

So you talk a lot about stress testing. There is 0 reason developers can't code stress testing and add as a step in the release cycle. You know why this never happens? Performance is never a requirement, almost always an afterthought. How many specs list required throughput or 99.99 percentile latency? No one cares about perf until it's bad. So if we fix that, put in the spec... We can automate perf testing and perf…

It's not that, so much as manual testers will /notice/ that code is slow, and ask questions about it, whereas automated tests will run the script no matter what (unless someone thought about it in advance)

Likewise, you /can/ code an automated test to simulate sudden network loss, but a human will just randomly decide to try it, without someone pre-programming him

Re: Ask HN: Help me see why everyone seems to love TDD?

#86

Post by flukus »

First of all, if your test are taking 40 minutes then they are integration tests, not unit tests. Not that there is anything wrong with integration tests, but they have different use cases. Integrations tests are much slower and can't test the edge cases like unit testing can, so they aren't suitable for TDD.

Secondly, I wouldn't sell TDD as such, I'd sell unit tests. Sometimes you write them before the code, sometimes after. There is no one size fits all.

Test coverage is a completely useless metric, so don't focus on it at all.

To sell unit testing, find the places with the hairiest logic "if a and b, do x, else do y, if y fails return z". This is where unit testing shines.

Next would be how to setup a test fixture. An individual test should take minutes (or less) to write. But to do this you need to have the test fixture setup properly. Create a happy path so that the tests can run without errors, dummy data, mocks, etc should be in the fixture setup, then the individual tests can just change these values and add to them.

Finally, the tests themselves. How to bring things down following the single assert principle so that changes should rearely break unrelated tests.

Re: Ask HN: Help me see why everyone seems to love TDD?

#87

Post by flukus »

raverbashing wrote: post #27
lcarlson wrote: post #18

Earlier quoted context omitted.

Hmm, having a test do anything more than one thing sounds like a functional or integration test.

Define "one thing" Suppose you want to test a function that capitalizes the first letter of words in a string: I would test '' => '' 'a' => 'A' 'aa bb' => 'Aa Bb' 3 tests, which does not mean 3 functions (that will have the overhead of setup and teardown)

I would make this a parameterized test for those common use cases and specific test for others ("o'tool" => "O'Tool").

The overhead of setup/teardown should be practically zero. Even having them as 3 separate functions should be take fractions of a millisecond.

The important thing is, it should be obvious why a test failed, you don't want more then 1 or two asserts.

Re: Ask HN: Help me see why everyone seems to love TDD?

#88

Post by flukus »

collyw wrote: post #56
amoerie wrote: post #16

Well, I'm not entirely sold on TDD just yet, but after applying it for a few years now, the benefits seem to be: - Requires you to think about structure before you write the actual code. Code that is unit testable is usually better code. (but not necessarily) - Requires you to think about the scenarios that you will support beforehand. - Ensures that every file is unit tested. Without TDD you can have untested files.…

Integration tests catch more bugs. In fact unit tests are fairly low on the scale, according to this: https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-...

Bugs caught is only one axis though, they other is effort. Unit testing is much lower effort, particularly for edge cases (what happens if dependency x throws exception) which may be hard/impossible with integration tests.

Re: Ask HN: Help me see why everyone seems to love TDD?

#89

Post by IanCal »

michaelmior wrote: post #41
pmontra wrote: post #22

Strictly speaking I don't do TDD because I don't write tests first. I write code first, then I write the tests. If I went tests first sometimes I would have to design the algorithm anyway because I wouldn't know what to test. However, I tend to write tests very early as soon as some code runs. Why? Because without tests I would feel like driving a car at night without lights and with no brakes. Sooner or later I'll c…

This is generally how I approach writing unit tests as well. Perhaps I'm doing TDD wrong, but I find myself running into the same problem as you that I often need to do too much design up front to write a test. The alternative is that I write the test using the simplest possible interface and then go back and continually change the test as I write the code. I've tried this but I haven't really found any benefit to th…

The risk with this is that your test is possibly not checking the thing you want. I have often found a test that passed even when the code wasn't working. Writing the test beforehand, when you know it should fail, helps get around that. You expect it to fail, then write code, then expect it to pass.

I like to at least test my test by commenting out the bit I just added, or somehow manually breaking the code somewhere to check it really does fail when the code doesn't work.

Post reply on HN