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

TDD Doesn't Work

blog.cleancoder.com

Post reply on HN
Print view View original

61–70 of 133 posts

Re: TDD Doesn't Work

#61

Post by ambrop7 »

crpatino wrote: post #53
ambrop7 wrote: post #42

Earlier quoted context omitted.

That's a good question. There are different ways: - Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found by that method, that have been missed by very formal verification processes). - Don't call it done until you haven't proven to yourself that the code has no bugs. This is an informal process of self-code-review but which involves quite rigorous thinking about…

> Play around with the program intelignetly and observe no bugs That's the most sophomore thing I have read in a long time!!! Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the off…

Right. In large projects some kind of automated tests are indeed useful. But they should not be a substitute for writing working code in the first place, just as an extra level of quality assurance.

Re: TDD Doesn't Work

#62

Post by gravypod »

I prefer to rather then write tests plan out the interactions between all components in large projects. This will show you how all the pieces interact and what cases to need to handle in each functional unit. After this, I sit down an write all the code.

After I know the organization of the source, I write out each functional unit of the code one at a time. As I go, I write each bit of test code for my source. After this I integrate every function unit.

If a change is needed, I go back to the drawing board and find a better overall organization. This happens often due to either performance constraints or the need to abstract a section further.

After this I'd consider embedding a unit test suite.

Works great for small to medium projects.

Re: TDD Doesn't Work

#63

Post by lisivka »

awinter-py wrote: post #39

Careful -- in these studies the subjects are writing tests before writing code. In practice there are 'test-heavy' devs who use factory data and the test suite to run skeleton code with crashpoints, and switch actively between test and imp files. This has tests & implementation being written in parallel vs strict TDD which has us finishing tests before writing program logic. Most test suites depend not just on functi…

TDD requires to write FUNCTIONAL test case first for every new feature. Functional test case should not depend on implementation. Integrational and unit tests are.

Re: TDD Doesn't Work

#64

Post by ambrop7 »

crpatino wrote: post #53
ambrop7 wrote: post #42

Earlier quoted context omitted.

That's a good question. There are different ways: - Play around with the program intelignetly and observe no bugs (you wouldn't believe how many bugs I've found by that method, that have been missed by very formal verification processes). - Don't call it done until you haven't proven to yourself that the code has no bugs. This is an informal process of self-code-review but which involves quite rigorous thinking about…

> Play around with the program intelignetly and observe no bugs That's the most sophomore thing I have read in a long time!!! Probably works OK if you are working alone in a simple product whose whole code mostly fits inside a single brain. Try doing that as part of a team of dozens that make daily changes to a code base of millions of lines and you will very soon earn the title of the most infamous person in the off…

BTW, can you elaborate on the meaning of "sophomore"? I can't find in a dictionary anything other than "second in a series" which doesn't seem to make sense in your use.

Re: TDD Doesn't Work

#65

Post by mjevans »

digibo wrote: post #31
aikah wrote: post #9

Earlier quoted context omitted.

Aren't tests supposed to be a tool to help design API? in that perspective a test should be written first. The problem IMHO is the choice of methodology as there is several kind of tests. Some may be more time consuming when it comes to the set up.

Personally, I think unit tests shine best when you're designing an API. I can swing from hate to love and back about TDD in minutes, but when it comes to thinking about how your code will be used, unit tests (did we stop using that term?) are a tremendously useful tool I have. I guess if all code written could be seen as an API, TDD would be great, but that's not the world I live in.

This is why I prefer free to implement open standards that are (hopefully) well designed and specific.

Inter-operablility and interchangeability of parts means that it's possible to validate an implementation to at least some degree.

The best example that I can think of off the top of my head is the OpenGL 4.4/4.5 work that is nearing conformance for the Mesa3D project ( https://en.wikipedia.org/wiki/Mesa_(computer_graphics) ); while the functional coverage for the main modern drivers is 'complete' the official conformance testing has already resulted in some bug fixes and additional areas to focus on improving.

That real life case study is yet another example of how an API and conformance tests built around that API result in better code and in a more consistent experience that isn't dependent upon a mono-culture implementation.

Re: TDD Doesn't Work

#66

Post by ivanhoe »

Author is only partially right about TLD being as "doing TDD in your head", since it's (at least for me) in a much more abstract form of a general idea, a concept, of what I want to achieve. When using TDD you need to come up with the very specific results that you will test and you need then to implement those specific tests, to the last line of code. This means that if you make any changes to the logic afterwords, you need to throw away your pre-written tests and write new ones, the time spent on writing them was wasted. TLD is much more flexible and easier to update, no code is thrown away if you change something. Before I start I just need to decide what I'm trying to solve with my current block of code, and then I later write a test to check if I did it properly. Then I do the next block of logic, and the next test. Since code blocks are directly related to the steps in my logic, it's very natural to come up with the tests for them, just test if the things work as you planned it. If in the middle of that work I realize that I need to do something in a completely different way, there's no pre-written tests, so no time was wasted on coding tests that were never going to be used. And, at least to me, this kind of situations happen a lot, I often refactor and improve things as I work on them, so for me TLD is much more suitable approach.

Re: TDD Doesn't Work

#67

Post by cocktailpeanuts »

bitL wrote: post #54
cocktailpeanuts wrote: post #37

Before I go in, I will state that in 99% of the times I'm a TDD hater. Actually I don't even like writing tests after the fact because I just like to build and move on. I could never understand why the ruby on rails tutorial insisted on walking newbies through TDD and skipped all chapters where they start talking about tests when I started learning rails. I still think it's a bad idea to make newbies do all the weird…

Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time.

Agreed, in my case what ends up happening is I start out with no tests but soon the project becomes huge and i have to start writing tests if I want to push stuff without fear.

The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be).

I think this is why this topic has been polarizing. Some people feel the need and some people do, depending on which role you're playing in your organization.

Nowadays interestingly, even the large companies are moving towards more testing because they can cut QA costs that way.

Re: TDD Doesn't Work

#68

Post by hawkice »

Let's say I have a new theory, called Understanding Driven Development. The system says:

It's a bug if someone needs to change code and they, at any moment, see code they don't understand. Stumbled into the wrong place? Bug filed for better notes on organization. The code you need to touch not understood? Understand what you see before you make a single change. If you change code and don't update docs, or documentation and code out of sync? It's a bug, and changing one to match the other _without detailed understanding_ is a bug too!

Now, that seems reasonable. And if a study comes out and says people can't make program changes faster, on average, when participants are given a bit of code identical, but with more (accurate and non-trivial) comments, that doesn't mean UDD doesn't work. It doesn't test it on real, full size applications. The code was the same, despite clarity of code is one of the goals of UDD -- one of the core claims is that UDD gets you better code to begin with. It focuses on a tiny test of something not necessarily core to the UDD mindset.

But it's evidence that at least one claim I've made is false. In fact, that study would be enough for me to throw that idea set into the garbage.

Re: TDD Doesn't Work

#69

Post by [deleted] »

ambrop7 wrote: post #38

I must be one of the very few people who can write working and mostly bugless code and without writing any kind of test. Writing tests feels like the most wasteful and possibly harmful thing to me (like by people forcing dependency injection etc. where otherwise unneeded). I don't really know what to think of the situation? Is this how it has always been? Do most software engineers really have no idea what they're do…

[deleted]

Re: TDD Doesn't Work

#70

Post by mannykannot »

Test-first was promoted as being the secret sauce that made TDD so much better than anything else, so this is something of a qualified vindication, but I do think (from my own experience) that writing down what I am thinking does help me see flaws that I had overlooked.
Post reply on HN