Need help designing some JUnit tests
in [Java Help]
|
From: Tom Anderson on 25 May 2010 08:27 On Mon, 24 May 2010, Arved Sandstrom wrote: > Rhino wrote: >>> Speaking as someone who occasionally sits in on job interviews, I'm >>> delighted when we find a candidate who's written any tests at all. >>> Most of them haven't. We don't expect people to know more than we do >>> (it would be great if they did) and we all learned as we went along >>> and wish we understood it better. >> >> As I said to Arved elsewhere in the thread, I find it frightening that >> anyone could apply for a job as anything more than a trainee programmer >> (one who didn't know anything about programming at all and was expecting to >> be trained by the employer) without having some familiarity with testing >> and, hopefully being able to demonstrate the familiarity. If that's the >> norm, then I feel better about my chances of getting a job programming in >> Java already :-) > > One good thing about TDD, which has been mentioned elsewhere in this thread > (and in other threads), is that you can slide tests in as part of the > implementation, with no non-technical managers any the wiser. A crafty move in this situation is to selectively write tests for the tricky bits. They'll help you get them right, and keep them right, with less effort, and that serves as a useful evangelical point. Once people see the utility of tests for some bits of code, they're on the road to seeing the utility of them for the whole codebase. tom -- Vive la chimie, en particulier, et la connaissance en general. -- Herve This
From: Arne Vajhøj on 25 May 2010 21:21 On 24-05-2010 17:27, Arved Sandstrom wrote: > Rhino wrote: >> Arved Sandstrom <dcest61(a)hotmail.com> wrote in >> news:jlvJn.4710$z%6.465(a)edtnps83: > [ SNIP ] > >>> 1. Code reviews/inspections and static code analysis with tools _are_ >>> a form of testing. Keep them in mind. >>> >> I see that you've given some good concrete suggestions for tools to >> use in upcoming paragraphs. Are any of these static code analysis >> tools? If not, can you suggest some good ones? I'd love to have some >> feedback on my code via code reviews too but that's a little difficult >> to do. It's not realistic to full (non-trivial) classes in the >> newsgroup so I just pick and choose especially concerning problems and >> post snippets reflecting them. I'm sure that you folks are all too >> busy to do detailed walkthroughs of dozens of classes with hundreds of >> lines of codes in many of them ;-) I must see if there is a local Java >> user group in this area and see if I can develop a few buddies for >> doing code walkthroughs.... > [ SNIP ] > > FindBugs, if you're not using it already, is a good static code > analyzer. In my experience, just one decent tool like that, plus the > requisite excellent books like Bloch's "Effective Java" and willingness > to spend time reading those books to understand what the analyzer tells > you, is all you really need. > > It's also useful to complement FindBugs with Checkstyle, which latter is > a good part of your toolkit for other purposes as well. Have you tried PMD? If yes how does that stack up against those two? Arne
From: Arne Vajhøj on 25 May 2010 21:28 On 21-05-2010 15:10, Tom Anderson wrote: > On Fri, 21 May 2010, Rhino wrote: >> Patricia Shanahan <pats(a)acm.org> wrote in >> news:NtWdndKRZMMkC2vWnZ2dnUVZ_j2dnZ2d(a)earthlink.com: >>> Arved Sandstrom wrote: >>> ... >>>> 5. Your tests are themselves defective. The sad truth is that if the >>>> core source code you just wrote is riddled with defects, then so >>>> probably are your tests. Main take-away here is, be aware that just >>>> because all your unit tests pass, some not insignificant percentage of >>>> those results are wrong. >>> >>> Although it is not 100% effective, there is some value in writing, >>> and running, the test before implementing the feature. Start testing >>> a method when it is just an empty stub. At that point, a test that >>> passes is either useless or has a bug in it. >> >> Fair enough. I saw an article just the other day that used a buzzword >> I've already forgotten which proposed that this was the right way to >> develop code: write test cases BEFORE you even start the code and then >> retest frequently as the code evolves. I can see some merit in that, >> even if I've forgotten the buzzword already ;-) > > Probably 'test-driven development', aka TDD. > > And it's no more of a buzzword than 'wearing a seat-belt'. It's just a > bloody good idea! I have no doubt that: success(TDD) > avg(success(all methodologies)) but I am not quite as convinced that: success(TDD) > avg(success(methodologies with strong focus on unit tests)) Unit tests is definitely good. But the middle D and its implications for the design process is more debatable I think. Arne
From: Arne Vajhøj on 25 May 2010 21:38 On 21-05-2010 14:37, Patricia Shanahan wrote: > Tom Anderson wrote: >> On Fri, 21 May 2010, Patricia Shanahan wrote: >>> Arved Sandstrom wrote: >>> ... >>>> 5. Your tests are themselves defective. The sad truth is that if the >>>> core source code you just wrote is riddled with defects, then so >>>> probably are your tests. Main take-away here is, be aware that just >>>> because all your unit tests pass, some not insignificant percentage >>>> of those results are wrong. >>> >>> Although it is not 100% effective, there is some value in writing, >>> and running, the test before implementing the feature. Start testing >>> a method when it is just an empty stub. At that point, a test that >>> passes is either useless or has a bug in it. >> >> The true extremos work to this rule - you must always start with a >> failing test, then work to make it pass. >> >> In fact, the way we (the programmers where i work) try to work is to >> write the test first, before even writing the stub of the method, then >> treat the fact that the test doesn't compile as a failure, and work in >> from there. > > This principle is also very important for bug fixing. Any bug represents > a defect in the test suite. Fix the test suite first, and verify that > the new tests fail, before any attempt to fix the underlying bug. Furthermore there is the phenomenon that if a bug was "natural" to make then there is an increased chance that some maintenance developer will reintroduce the bug later. We want to catch that. Reintroducing bugs does not make bosses and customers happy. Arne
From: Tom Anderson on 26 May 2010 04:37
On Tue, 25 May 2010, Arne Vajh?j wrote: > On 21-05-2010 15:10, Tom Anderson wrote: >> On Fri, 21 May 2010, Rhino wrote: >>> Patricia Shanahan <pats(a)acm.org> wrote in >>> news:NtWdndKRZMMkC2vWnZ2dnUVZ_j2dnZ2d(a)earthlink.com: >>>> Arved Sandstrom wrote: >>>> ... >>>>> 5. Your tests are themselves defective. The sad truth is that if the >>>>> core source code you just wrote is riddled with defects, then so >>>>> probably are your tests. Main take-away here is, be aware that just >>>>> because all your unit tests pass, some not insignificant percentage of >>>>> those results are wrong. >>>> >>>> Although it is not 100% effective, there is some value in writing, >>>> and running, the test before implementing the feature. Start testing >>>> a method when it is just an empty stub. At that point, a test that >>>> passes is either useless or has a bug in it. >>> >>> Fair enough. I saw an article just the other day that used a buzzword >>> I've already forgotten which proposed that this was the right way to >>> develop code: write test cases BEFORE you even start the code and then >>> retest frequently as the code evolves. I can see some merit in that, >>> even if I've forgotten the buzzword already ;-) >> >> Probably 'test-driven development', aka TDD. >> >> And it's no more of a buzzword than 'wearing a seat-belt'. It's just a >> bloody good idea! > > I have no doubt that: > > success(TDD) > avg(success(all methodologies)) > > but I am not quite as convinced that: > > success(TDD) > avg(success(methodologies with strong focus on unit tests)) You may be right. I tend to think: TDD == methodologies with strong focus on unit tests Although that's probably just my biases. What are other methodologies that have a strong focus on unit tests? Are they test-first or test-after? What is a test-first method that's not TDD? tom -- Once you notice that something doesn't seem to have all the necessary parts to enable its functions, it is going to mildly bug you until you figure it out. -- John Rowland |