Earlier quoted context omitted.
In this case, I think Kent's right. Joel's doing it wrong. You should never have 10% of your unit tests depend upon the location of a menu. You should have one unit test that depends upon the location of the menu, and everything else should be isolated by stubs, shunts, mocks, whatever. Otherwise, they aren't really unit tests, because they're testing more than a unit. I didn't realize how wrong I was doing it until…
Do you know of any good texts or articles that describe the "right" way to test? I put myself in the category of mediocre test writer, because I do bump into the problem fairly regularly of having a lot of tests fail when I do a rewrite. I'd love to learn how to write better tests...and your last paragraph seems to scratch the surface of a superior approach.
"Joel Spolksy is wrong about my work" - Kent Beck
51–60 of 100 posts
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#52Here's a transcript of the podcast I believe Kent is referring to. Judge for yourself whether Joel "makes comments that make clear his lack of knowledge". http://www.joelonsoftware.com/items/2009/01/31.html I'd like to see Kent respond to Joel's specific points. E.g: The real problem with unit tests as I've discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentag…
And, BTW, I never found Joel Spolsky a particularly insightful person.
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#53Earlier quoted context omitted.
> After the changes, you know there's probably bugs, but you don't know where. Which highlights one of the "problems" with unit tests: if something fails, you have to take time to go and fix it. If you have no tests, you can assume there are no bugs because you are such a great programmer, then go home after a job well done. That there actually are bugs there doesn't bother you, because you don't know about them. It…
The alternative, is to build you code in a way which tells you quickly about bugs... decent logging, etc
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#54Earlier quoted context omitted.
'Fraid not, axod. It's when you're quickly iterating and changing lots of stuff that quality unit testing helps you the most. Let's look at 2 possible scenarios: 1) You don't bother testing much. You make lots of changes, iterate quickly. Before the changes, you have code that, let's say, you know works. After the changes, you know there's probably bugs, but you don't know where. 2) You test fairly thoroughly. You ma…
There are two schools of thought in programming I have seen. 1. Design it right the first time, tests and all. 2. Build a throwaway, no tests, little refactoring as you quickly iterate Programmers who fall into category 1 in my experience mistakenly believe that they understand the requirements of the software they are writing. Category 2 programmers tend to be ones who actually deal with users/real world, and know t…
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#55Earlier quoted context omitted.
'Fraid not, axod. It's when you're quickly iterating and changing lots of stuff that quality unit testing helps you the most. Let's look at 2 possible scenarios: 1) You don't bother testing much. You make lots of changes, iterate quickly. Before the changes, you have code that, let's say, you know works. After the changes, you know there's probably bugs, but you don't know where. 2) You test fairly thoroughly. You ma…
>> "Before the changes you have code that you know works. After the changes, you know where most of the bugs are because your tests tell you where they are." No. More often than not, if you change was a large architectural one, which is often the case in young software, your tests are now irrelevant, or broken. >> "It's the difference between walking with your eyes open or closed... it may be more work to process all…
If you change that into writeAnAutomatedTestForItAndRunYourTestSuite() you get the following benefits:
1) Every test you write accrues value onto your test suite and helps you avoid problems later;
2) You don't need to spend time to figure out what you might have broken with your change - your test suite tells you in seconds;
3) You can say with some measure of certainty that it's extremely unlikely that your change broke anything.
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#56It sucks to have your life's work strawmanned like this by pop programmer podcast banter. I hope Joel addresses it professionally. XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed b…
This is a mud-slinging contest over a subject with dubious value to software development in general. it might just be me, but whenever I hear TDD/Agile/XP my heart is made sad by all the crap out there in software development.
I want to design and write good programs. Now of course, that might include testing the software for errors in an automated way. I would think that most people would agree on testing as a needed tool for most software developed today and in the future.
But there is a long way from testing a piece of software to the extreme views. And there, we see all kinds of disagreement. Hence the mud slinging. This is a bad bragging contest. And it is just going to take up your time. You won't gain anything from it unless you take stance. Here is mine:
XP: Crap. Kill it. It completely disagrees with the way I can work soundly on a project. But take the code review part with you.
TDD: Crap. Kill it. It completely disagrees with the way I develop software. Sorry. I am not going to change. And I am not becoming extinct because of my view either.
Agile: Take the old ideas of iterative development and short development cycles. Take the good idea of keeping the development methodology simple. Take the good idea of providing transparency of the development status. Kill everything else.
Now your stance might be different from mine. But we will gain little by discussing the finer points.
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#57Earlier quoted context omitted.
In this case, I think Kent's right. Joel's doing it wrong. You should never have 10% of your unit tests depend upon the location of a menu. You should have one unit test that depends upon the location of the menu, and everything else should be isolated by stubs, shunts, mocks, whatever. Otherwise, they aren't really unit tests, because they're testing more than a unit. I didn't realize how wrong I was doing it until…
Do you know of any good texts or articles that describe the "right" way to test? I put myself in the category of mediocre test writer, because I do bump into the problem fairly regularly of having a lot of tests fail when I do a rewrite. I'd love to learn how to write better tests...and your last paragraph seems to scratch the surface of a superior approach.
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#58It sucks to have your life's work strawmanned like this by pop programmer podcast banter. I hope Joel addresses it professionally. XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed b…
You can read about that experience here:
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#59It sucks to have your life's work strawmanned like this by pop programmer podcast banter. I hope Joel addresses it professionally. XP/Agile/TDD (like any movement) is filled with rabid fanboys who misapply the principles and try to ram them down everyone's throat, but it's rarely the case that the inventors of popular methodologies are filled with the same blind zeal. After all, their ideas were originally informed b…
I think that the whole movement idea of software development is pretty weak. If Joel can write down a life's work in a couple of sentences, then there is definitely not much to it in the first place. This is a mud-slinging contest over a subject with dubious value to software development in general. it might just be me, but whenever I hear TDD/Agile/XP my heart is made sad by all the crap out there in software develo…
You seem to presume that Joel has written down Beck's life's work in a couple of sentences. The whole point of Kent's post is to refute this presumption.
Joel himself wrote a post giving a twelve-point "Joel Test" for software development practices: http://www.joelonsoftware.com/articles/fog0000000043.html
I'm sure you agree that Joel did not write down his own life's work in articulating twelve simple yes or no questions about software development practices. There's more to Joel's own experience than those twelve questions, and there's more to Kent's life's work than Joel's off-hand remarks.
I'll close my rebuttal to your comment by pointing out that you have just summarized your own stance on software development with some amazingly superficial and non-actionable prescriptions.
But I would never presume that these prescriptions, right or wrong, would summarize your life's work either. Nor would I jump to hasty conclusions about your experience based on whether I agree or disagree with your stance on TDD.
Re: "Joel Spolksy is wrong about my work" - Kent Beck
#60His company makes bug tracking software!
Of COURSE he wants to cast unit testing in a bad light - done properly, it could put him out of business.