Need help designing some JUnit tests
in [Java Help]
|
From: Rhino on 21 May 2010 20:28 >>> So, if the constructor doesn't >>> throw any exceptions and is public, you say that I should test that >>> "the returned values exists and is not null". >> >> Non-nullity of the return value should be handled by an 'assert' in >> the factory method, and therefore not necessary to test in the unit >> test. Existence is already guaranteed by the successful return of the >> factory method. >> > I'm not very familiar with "assert". I'll look into it on my own and > add that code. > Followup question. I just read up on assert and it is apparently not supposed to be used in public methods. Since it is my getInstance() method that invokes the private constructor, the getInstance() is where I'd put the 'assert' right? After all, my constructor is completely empty. If I follow the rule about not using 'assert' in public methods, I'm not sure how to reconcile you advice with the rule in the assertions article (http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html).... >>> What's my best way of doing that? Am I right in assuming that a >>> simple >>> >>> if (Foo != null) >> >> Ummm, 'Foo' is a class, right? It better be, and therefore that line >> will not compile. >> >>> will cover both of those? >> >> How about 'assertNotNull( fuzz );'? >> > > That would go in the test case (as opposed to the class) and wouldn't > be redundant with the 'assert' you mentioned that should go in the > class itself? > Is the assertNotNull in the test case a reasonable substitute for doing the assert in the getInstance()? -- Rhino
From: Lew on 21 May 2010 20:36 On 05/21/2010 08:28 PM, Rhino wrote: > Followup question. I just read up on assert and it is apparently not > supposed to be used in public methods. Since it is my getInstance() method Wrong. > that invokes the private constructor, the getInstance() is where I'd put > the 'assert' right? After all, my constructor is completely empty. > If I follow the rule about not using 'assert' in public methods, I'm not That's not a rule. You are not reading the advice carefully. You're not supposed to use 'assert' to validate arguments to a public method. There are plenty of use cases for 'assert' in a public method. > sure how to reconcile you advice with the rule in the assertions article > (http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html).... Read the article again, more carefully. The purpose of 'assert' is to prove that invariants hold. It's actually not so far different from the JUnit 'assertXxx()' methods, where 'assert' proves within the code itself that algorithmic invariants hold, and JUnit's assertions prove that test invariants hold in a test class outside the code itself. Both throw 'Error's when violated. > Is the assertNotNull in the test case a reasonable substitute for doing the > assert in the getInstance()? Not really. They don't really do the same thing, exactly. -- Lew
From: Arne Vajhøj on 21 May 2010 20:25 On 21-05-2010 14:59, 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 ;-) TDD http://www.agiledata.org/essays/tdd.html Arne
From: Arne Vajhøj on 21 May 2010 20:23 On 21-05-2010 15:11, 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 :-) You would be surprised how many total clueless (wannabee) programmers there are. Arne
From: Arne Vajhøj on 21 May 2010 21:13
On 21-05-2010 08:51, Arved Sandstrom wrote: [lots of stuff that I completely agree with] > 3. Code coverage - Huge, IMO. How can you know that your unit tests or > integration tests (or even human-tester-driven acceptance tests) are > doing any good unless you know how much of the code is actually being > exercised? Code coverage is very simple to do, and for starters you > can't go wrong investigating Emma or Cobertura. These simply instrument > the Java bytecode, such that when the bytecode is executed (by any > mechanism) coverage counts by line/branch/method/class/package are > written to HTML or XML reports. Note that unit tests to achieve 100% code coverage is not sufficient - one need to test every path through the code (CCN). Arne |