31–40 of 42 posts
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
Also, code that controls hardware is very hard to test. Consider writing tests for the the Linux kernel's device drivers. It would be very difficult because most of the problems have to do with hardware being buggy/underspecified, not with the software being wrong in a testable way. In order to test a UART driver you have to to simulate the way the UART worked, which means that you wouldn't catch bugs if your underst…
First, write code that "tests" the actual hardware, that means it drives the hardware and checks its results. Verify using whatever means you have available that it drives the hardware correctly.
Second, create a variant of this first test (class) that runs against your simulator (checking for the same results). I used a trivial subclass that changed nothing except replacing the device interface with the simulator.
Third, write your simulator against these tests.
Fourth, use your simulator to test the remainder of your system without requiring the hardware/external system.
Extend when you make use of new features, and occasionally test against the real system/hardware...
TDD is awesome, if you have a codebase or a tech stack that makes it nice. TDD will quickly expose bad design through an unpleasant testing process. For example, slow tests, untestable code, or tests that you "always have to rewrite/maintain" are problems that only show up when you try and TDD your code that isn't designed to be testable. TDD doesn't work well if you don't design your code to be testable because you…
> TDD isn't for everyone because not everyone is willing to make those kind of investments in code quality and maintainability. One thing I've noticed is that code written to be testable tends to suffer from over-abstraction. Sadly, writing nice, compact, easy to read code is somewhat at odds with TDD in my experience. I personally don't like that I have to make sacrifices to code simplicity just to make it testable.…
If you are making code overly abstract, that does suggest you may be overthinking your TDD approach.
He left out "You are Donald Knuth"
In any event, I find that using literate programming results in less buggy and more comprehensive code.
This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.
Agreed this was completely pointless. Bottom line is not every line of code needs testing, and TDD alone does not have an impact on code quality. There is nothing I hate more than bad code covered by even worse test code. Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ Bottom line is that writing TDD style unit tests won't make crap c…
Earlier quoted context omitted.
Agreed this was completely pointless. Bottom line is not every line of code needs testing, and TDD alone does not have an impact on code quality. There is nothing I hate more than bad code covered by even worse test code. Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ Bottom line is that writing TDD style unit tests won't make crap c…
Not entirely true: If you write tests, chances are you're educating yourself on how to write them. As a consequence, code gets improved - because it's almost impossible to write any kind of tests if the code is crappy. But then again, maybe that's just me :)
As for the educating yourself part, yes you'll become a better dev if you are just starting out writing tests. But at some point you'll either become less dependent on them or dogmatic about them. I prefer the former.
I'm a strong proponent of TDD. In my experience its more productive, and results in better software. But.... I've been in this position before: We have a large existing codebase with no unit tests to speak of, and the business is not willing to fund efforts to refactor or add unit tests. It is very hard to add unit tests after the fact. Not impossible, but its alot of work, and business folks really don't care.
TDD is test driven development. You are talking as though TDD is same as adding unit tests.
So you can't really do TDD for your new code without refactoring the existing code-base. But refactoring the existing code-base without good test coverage is nasty.
He left out "You are Donald Knuth"