Live data from Hacker News

An External Replication on the Effects of Test-driven Development [pdf]

people.brunel.ac.uk

331–332 of 332 posts

Re: An External Replication on the Effects of Test-driven Development [pdf]

#331

Earlier quoted context omitted.

I've actually found that most QA people I've worked with were good at deciding what to test but were awful at writing automated tests. Of course that's purely anecdotal and based on a very small sample size. I like to believe that I sometimes will forget to test for edge cases, but have mastered how to write tests. I don't think that how to write tests is easily acquired by any descend programmer. However, you need t…

The real strength of QA people can be manual testing. There's a local maximum of "meets the stated requirements but horrid to actually use", and a singular focus on test automation seems to push projects in that direction.

Totally agree. I think they are great for what some people refer to as "exploratory testing".

Re: An External Replication on the Effects of Test-driven Development [pdf]

#332

Earlier quoted context omitted.

That means you can't use coverage tools, so this approach makes the tests unquantifiable. It is not how most major dev shops work, because of the bean counters and the "senior" developers/leads/managers/... who seem to want nothing but appeasing beancounters. It also produces superior software in my experience.

It's been very YMMV in mine. For some things, it's indispensable. Others it's tedious, repetitive and of questionable benefit.

Automatic test generation tools. There's quite a few on github, but the real ones are the ones you write yourself. What you're looking to do is to run the software a few times and record tests for particular pieces of code during those manual tests.
Post reply on HN