Test-Driven Development is Stupid • Hacker News Board

Re: Test-Driven Development is Stupid

#131

Post by warkid » Tue, Nov 24, 2015, 4:08 PM UTC

TeMPOraL wrote: post #24

Way stronger than I'd write, and I don't agree with it entirely, but the author has a point. Personally, what annoys me the most about TDD I've seen in the wild are two things: designing for tests instead of actual problems, and tests affecting the structure of "real" code. Designing for tests - the standard TDD approach, first we write tests, then we write code to pass the tests. Quite often the consideration of the…

> Personally, what annoys me the most about TDD I've seen in the wild are two things

It's like saying that one is annoyed by programming in general because he's seen too many horrible things done with it! Anything can be abused, TDD is not an exception.

> your tests become more complicated than the tested code

Well, then don't tdd that code on unit level. Keep some high-level(smoke, integration etc) tests that executes it , relax and write/design it without TDD the best way you can.

> Tests affecting the structure - this is IMO a strong code smell.

Yes, and this smell (by definition) shows you a flaw in the code design. TDD helped to identify this. Apparently)

Re: Test-Driven Development is Stupid

#132

Post by akshatpradhan » Tue, Nov 24, 2015, 4:14 PM UTC

alkonaut wrote: post #8

mabbo wrote: post #6

> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.

This. I agree TDD can cause more harm than good in software design, but my test suite saves me from shipping several regressions per day that I would have otherwise not noticed. Obviously if you are against testing in general you are against TDD (it's just testing taken to the extreme). I thought he at least was going to say that he preferred higher level testing, to low level unit tests (which can be a fair point, y…

How does TDD cause more harm than good in software design?

Re: Test-Driven Development is Stupid

#133

Post by dllthomas » Tue, Nov 24, 2015, 4:23 PM UTC

mannykannot wrote: post #96

theseatoms wrote: post #70

Earlier quoted context omitted.

>You are writing code to test something that doesn't even exist yet. To piggyback on this... sure, the code doesn't exist yet, but the project specs do. And unit tests can help by making the required specification explicit.

I agree, but the corollary of that is that if the project specs exist (and they do, at least conceptually), then it is they that are ultimately driving development. This is outside of the scope of TDD, and so TDD is not a complete methodology, a fact that often seems to be forgotten or overlooked.

I've been wanting (and, off and on, building) a system for tying documentation to supporting tests. On the one hand, it should serve as citations, making sure I don't make claims I can't hold up. On the other, it should help avoid the docs drifting out of sync with the code without undue cognitive overhead - telling me what I need to consider changing when the code changes.

One option would be to start with a spec and gradually add citations, doing TDD along the way for a sort of Documentation Driven Development, although I've no particular confidence that's actually a sweet spot.

doctest is a move in this direction, but only really makes sense for code you wish to surface as examples. Cucumber is also obviously related, but - so far as I understand - isn't really suitable for producing arbitrary documentation. Types are (amongst other things) another form of machine checked documentation, but the audience (and, usually, expressiveness) is naturally limited.

Re: Test-Driven Development is Stupid

#134

Post by davnicwil » Tue, Nov 24, 2015, 4:24 PM UTC

zeveb wrote: post #37

mabbo wrote: post #6

> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.

I think I see part of his point, though. By its nature, a unit test is (often, albeit not necessarily) tightly coupled with the thing it is testing--which means that anyone who changes the implementation must change the test, which increases the complexity of code changes. I know that in my own work, the single most important thing for me is to be able to massively refactor, restructure and redesign my and others' co…

> all unit tests should be written to test the external interface, not the internal details

Yes, this is the most useful approach to unit testing. If you have a functional interface which doesn't cause side effects, (i.e. state changes of any kind, external actions that can't really be effectively verified by test code, etc) then unit testing is very valuable and useful given you just test the interface using the simplest possible approach: a table of some inputs which should map to some outputs.

I'd go further and say you should always write the tests only after this interface has solidified. Test first makes sense only under either the assumption that your first design is always the best design, or that you are happy to spend the time to morph the tests, as well as the code when you realise your first design wasn't the best and have to iterate and tweak.

We all know from experience that the first assumption is never true. As for the second assumption, it may be true, but then the question becomes, well, why waste the time? You know those 'test-first' tests will just be rewritten anyway. Why not just write the tests last and save yourself a lot of wasted effort?

Re: Test-Driven Development is Stupid

#135

Post by kul_ » Tue, Nov 24, 2015, 4:29 PM UTC

I tend to agree with this. First, no I am not against writing unit tests, they are great way to trap regressions. But test driven DESIGN? really?

Do you drive your car (software) by banging against rail guards (unit tests) to reach a destination? They are there so that you do drive off the road accidentally not guide your way.

Re: Test-Driven Development is Stupid

#136

Post by dllthomas » Tue, Nov 24, 2015, 4:32 PM UTC

snowwolf wrote: post #125

DougWebb wrote: post #114

Earlier quoted context omitted.

I've always found that if you can't write the test first it's a good indication that you probably don't yet have a good enough understanding of the problem you are trying to solve. The author's point, in the painting comparison and when mentioning other fields, is that you never have a good enough understanding of the problem you are trying to solve when you're just starting to work on it. Developing the code is an i…

And my point is the opposite Developing the tests is an iterative process that refines your understanding of the problem and the correct solution, and only once you've done that do you know enough to write appropriate code.

On a related note, when it comes to types I find very odd the persistent notion that a statically typed language means it's vital that you get the types right at the outset.

Quite the contrary, as we build anything, we necessarily pick some way of organizing our code and our data. When we inevitably discover that we were horribly wrong, it is tremendously valuable to be told more about what needs to change in concert as we reorganize.

Re: Test-Driven Development is Stupid

#137

Post by dllthomas » Tue, Nov 24, 2015, 4:37 PM UTC

DanielBMarkham wrote: post #124

blub wrote: post #116

Earlier quoted context omitted.

Unfortunately when it comes to software development, you can count on many techniques, processes and tools being exactly that: fads packaged expertly by consultants and salesmen to be gobbled up by the masses of managers, architects and developers in exchange for big bucks from trainings, courses and certificates. And you can bet that they will oversell it, hype it and denounce everyone that's trying to be reasonable…

Damn. The misunderstanding just goes on and on. TDD is not a unit testing religion. It's a way of designing software. Some have even advocated calling it Test-Driven Design, not Test-Driven Development, because the end result is a design, not a series of tests. This is important to know, because the key factor in the red-green-blue cycle is the blue step: refactoring. The example given by the author is of a system th…

"In this case, they were not doing the most important thing in TDD, refactoring. Not really sure you can even call this TDD. Looks more like a CF created by a bunch of folks under time pressure who thought it would be easier to add stuff than refactor."

To be fair, this is a common failure mode when people try to do TDD.

(to be clear, common amongst failures; not necessarily most common amongst failures, and not necessarily a terribly common outcome overall)

Re: Test-Driven Development is Stupid

#138

Post by alanfranzoni » Tue, Nov 24, 2015, 5:10 PM UTC

Scarblac wrote: post #67

alanfranz wrote: post #16

There're already people speaking about the limits of a too strict TDD: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... And yes, it may be stupid to test before a design emerges - but only if you start with a very fine-grained test. Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved cre…

> Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved creating and designing multiple classes) I probably have a working design and I may begin creating other, smaller unit tests for individual components. That is exactly how I start coding something from scratch, except I don't have that initial test.…

It offers the value of having an initial target, otherwise you risk coding too much without stopping.

Re: Test-Driven Development is Stupid

#139

Post by k__ » Tue, Nov 24, 2015, 5:10 PM UTC

In my first big project after university, a RPC API, I used test driven development and it felt really good. I had about 300 tests in the end and if I changed something, a few would blow up and I could fix it.

But it slowed development down massively.

In the start because I had to set up the testing as I had to setup the real software.

Then I had to mess around with the testing framework as I had with the projects frameworks.

Also I had to write features AND write their tests.

And later in the project, when new features broke old stuff not only the features had to be fixed but also the tests.

I don't know, but I had the feeling that the time I spent with the test-code was the same I would have spent with fixing possible bugs later.

Re: Test-Driven Development is Stupid

#140

Post by icebraining » Tue, Nov 24, 2015, 6:15 PM UTC

blub wrote: post #126

DanielBMarkham wrote: post #124

Earlier quoted context omitted.

Damn. The misunderstanding just goes on and on. TDD is not a unit testing religion. It's a way of designing software. Some have even advocated calling it Test-Driven Design, not Test-Driven Development, because the end result is a design, not a series of tests. This is important to know, because the key factor in the red-green-blue cycle is the blue step: refactoring. The example given by the author is of a system th…

Daniel, there is no misunderstanding, I know about the two definitions of TDD - one focusing on testing and one on design. I think that automated unit testing is a useful method of reducing errors and regressions, however not alone but as part of a series of quality control strategies such as integration and higher level and manual testing, static and dynamic analysis, using higher level programming concepts, etc. I…

Testable code is often less encapsulated, contains extra complexity for the test machinery, among which we can count extra methods (with potentially non-private visibility) and dependencies between classes (such as strategies, policies, factories, etc).

I think that's a more a consequence of poor testing libraries/frameworks than of TDD itself. A method shouldn't have to be turned non-private to be tested.

Furthermore, while designing at the class level is important, it is much more important to architect at higher levels: component, subsystem, application, system/platform. All of these aren't considered when writing unit tests and what makes perfect sense in a "unit" might only be a local optimum.

It's TDD, not UTDD.