Live data from Hacker News

Giving up on test-first development

iansommerville.com

221–224 of 224 posts

Re: Giving up on test-first development

#221

"...because I think it encourages conservatism in programming, it encourages you to make design decisions that can be tested rather than the right decisions for the program users.." - Couldn't agree more with this.

Reminds me of an article written by the creator of Ruby on Rails.

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv...

Re: Giving up on test-first development

#222

Earlier quoted context omitted.

> If I need a custom sort algorithm for my product, I'm going to write unit tests for it's implementation. I would start with writing an assertion about the end state of the sort. Then using syntactic substitution of the predicate calculi derive the program by assertions. I'd then have a specification of the algorithm as a mathematical model from which I can check every possible execution for the entire domain on the…

Would you actually do this, or do you just like to imagine a world where people do this? I'm familiar with Coq and Prolog(one of which I think you're hinting at), but I'd reach for Perl or C over either one if I needed to write a trading program or generate a statement from my accounting software or something.

I learning to use these techniques in my everyday work (cloud software).

I think of it like this: nobody is going to care if I screw up the script to balance my accounts. If I write some software that messes up the balance of everyone's account in some bank then someone is going to care.

I don't think formal methods and rigor are the sole domain of government institutions, avionics control software, and industrial robotics. The public relies on the cloud and the applications that run on it and they have no recourse if their data is exposed or disappears.

Imagine if instead of crossing over a bridge you were stopped at a booth and asked to sign a wager stating that nobody is liable if the bridge collapses underneath you while you cross it. Rich or poor, regardless of how much you pay in taxes, you should be able to rely on that bridge being built to the highest standards we know how and someone should be liable if it falls down. You can rely on this in real life. Why do we not have this for software?

I'm not saying I write all of my software using formal methods and rigorous proofs. It's often good enough to sketch my idea on the back of a napkin when I'm building a tool shed. But nobody built a sky-scraper without doing a little math and being fairly rigorous in their thinking.

Re: Giving up on test-first development

#223

Earlier quoted context omitted.

TDD is not about reduction of bugs, or race conditions. Robert Martin has said that reduction of bugs is not sufficient enough to warrant using TDD for code. TDD is about achieving better designed code that is maintainable and readable for many years. TDD uses unit tests, not integration tests. So, the behaviour of each function is asserted independently. Maybe you have a function that sets up a data structure at a p…

> TDD is about achieving better designed code that is maintainable and readable for many years. It isn't entirely clear to me why this is true. Clearly, TDD forces you to think beforehand about what you want your program to do, since that's ultimately what a test suite is: an executable description of what you want your program to do. However, it doesn't necessarily follow from this that your code will be well-design…

Tests in TDD are focused on behaviours required by the problem being solved. One rule in TDD, as Kent Beck lays it out, is if you can't design and complete a test (of behaviour) in under 10 minutes, you haven't broken down the original behaviour enough yet. He uses the simple reminder "start small or not at all". TDD is the very method of evaluating a design. However, keep in mind that this refers to the mechanics and details of a more global overarching design. You still start off with a plan and "bigger design".

TDD in this manner breaks down problems into small manageable chunks of unique behaviour very specific to the problem they are solving. Combine this with the refactoring step, and the code becomes simple to understand and readable. It's very important to note though, that a complex problem will always be complex. TDD does not remove the complexity of the problem domain.

Re: Giving up on test-first development

#224
post #137

Earlier quoted context omitted.

How many of those side projects ended up being 6 million lines of code maintained over 5 years? Because those are the kind of code bases I have in mind when I'm weigthing the pros and cons of TDD or other testing practices. When reading Uncle Bob and others I have always got the feeling that the "goal" of the practices described is to have systems that can be maintained and extended for years by different people and…

it's like i'm an artist. You can't tell an artist how to paint. I'm going to paint my best work when I'm allowed to choose my own easel and pallette and brushes. Let me throw some green paint on the canvas and make the trees how I wanna make the trees. Programming is more art than science.

I feel like most artists produce inferior results when they are allowed to fully express themselves with infinite resources and no limitations.

When George Lucas was given unlimited time and money, he produced inferior films.

McCartney and Lennon's solo efforts don't stand up to their collaborative works.

Elvis eventually became fat, gaudy Elvis.

Post reply on HN