Need help designing some JUnit tests
in [Java Help]
|
From: Tom Anderson on 21 May 2010 15:10 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! tom -- Don't trust the laws of men. Trust the laws of mathematics.
From: Rhino on 21 May 2010 15:11 > 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 thing you might do is run some of Super's unit tests on Sub >>> instances. Another might be to include a "sanity check" test in >>> your Sub, something that reflects on Sub and verifies that the >>> methods you've chosen not to test are in fact inherited. >>> >> >>> Finally, you've got to realize that unit testing, important as >>> it >>> is, is not the be-all and end-all of verifying correctness. >>> >> I have no problem with that at all. If there are certain things I >> don't need to cover in unit testing, that's perfectly fine. If you or >> anyone else reading this could point me a good summary of what is and >> is not a concern in unit testing, that would be very helpful. Again, >> I have effectively NO formal training and what much of the on-the-job >> stuff I have was learned many years ago. That means that my memory of >> the theory is very incomplete at this point. In short, I don't know >> what the prevailing theory is on exactly what should be covered by >> unit testing, acceptance testing, regression testing, et. al. I'm not >> going to worry about anything beyond unit testing for the moment but >> if anyone can point me to a general - and hopefully fairly brief and >> example-laden - discussion of the prevailing theories of testing, >> that would be very helpful. > > In the specific case of a utility class, what I look for is clear > Javadoc. I need to be able to decide, without wasting a lot of time, > whether a method does what I need or not, and how it handles corner > cases. For an example of how I like to see it done, go to > > http://commons.apache.org/lang/api-release/org/apache/commons/lang/Stri > ngUtils.html > > and look at, say, the definition for > > center(java.lang.String, int) > I come pretty close to that standard in my better Javadoc comments. Thank you, this gives me a good standard to emulate in ALL of my Javadoc comments! > Notice that once you have a good definition of how the method should > behave, writing a unit test for it is straightforward. > Yss and no. I don't have a lot of trouble with what to test in routine methods but, as you can see from the first part of the thread, the proper testing for some methods, like Constructors and getInstance() methods isn't quite that obvious to me. But it's becoming a lot more clearer as a result of this thread :-) > Notice also that testing a utility class is very different from > testing a program or an application framework. > I hear you. I've got a variety of different projects - servlets, midlets, GUI-centric programs, as well as more standard Java classes - and I've got a running question in the back of my mind about how to test some of them. But I'll leave questions of that kind for another day. I can't learn everything I don't know in a single day or a single newsgroup thread ;-) -- Rhino
From: Rhino on 21 May 2010 15:13 Eric Sosman <esosman(a)ieee-dot-org.invalid> wrote in news:ht5uk1$80r$1 @news.eternal-september.org: > On 5/21/2010 7:08 AM, Rhino wrote: >> Lew<noone(a)lewscanon.com> wrote in news:ht4ghr$cbl$1(a)news.albasani.net: >> >>> Rhino wrote: >>>>> if (Foo == null) fail("Constructor failed to instantiate the >>>>> class"); >>> >>> Eric Sosman wrote: >>>> Rhino, if you keep on spewing this sort of codecrap I'm going >>>> to shove that horn of yours firmly up the orifice that spews. >>> >>> Rhino, the source of Eric's irritation is that despite apologizing >>> profusely multiple times for posting uncompilable code, you did it >>> again anyway. >>> >>> Apologies don't help much if you don't correct the behavior. >>> >> For what it's worth, I never imagined that anyone was actually going to >> compile that code. I just provided that (sort-of) code for illustrative >> purposes. [...] > > Nobody was probable to compile the code, not. But a fragment > in full load of the errors is not the "illustrative," it is only > offuscatorio. In order to extract the meaning from a beautiful > insignificant piece of the code, the reading of the person must > make the changes and corrections to arrive to something images that > you could have in mind and are every probability that will supply > some different thing from what has meant and that its ulterior > observations therefore will be not at all useful you. > > (In other words: "Illustrate" your thoughts with garbled > utterances, and people may form opinions about your thinking.) > I get your point now and it is very reasonable. I'll try to do better in future! Thanks for your patience and sorry for the confusion. -- Rhino
From: Patricia Shanahan on 21 May 2010 16:04 Rhino wrote: > Am I right in assuming that it is reasonable to bypass the sequence > testing in the case of my sorted list of Locales, given that I am using a > TreeMap which already guarantees the order? I assume you are just > including these tests to cover situations where I am generating a sorted > list out of thin air (without the benefit of the TreeXXX Collection > classes) so that I can be confident my code worked correctly? I would test it. Suppose at some future time a programmer changes the Map implementation e.g. from TreeMap to HashMap. That might be done in an attempt to improve performance, or because of a future decision to standardize on HashMap unless there is a specific reason to use a different implementation. The future programmer could be yourself after you have had time to forget why you used TreeMap. If you test for alphabetical order, the method's unit test will fail with HashMap. If not, you could get a clean unit test, but have all the fun of debugging system level problems. Patricia
From: Tom Anderson on 21 May 2010 16:17
On Fri, 21 May 2010, Patricia Shanahan wrote: > Rhino wrote: > >> Am I right in assuming that it is reasonable to bypass the sequence >> testing in the case of my sorted list of Locales, given that I am using >> a TreeMap which already guarantees the order? I assume you are just >> including these tests to cover situations where I am generating a >> sorted list out of thin air (without the benefit of the TreeXXX >> Collection classes) so that I can be confident my code worked >> correctly? > > I would test it. > > Suppose at some future time a programmer changes the Map implementation > e.g. from TreeMap to HashMap. That might be done in an attempt to > improve performance, or because of a future decision to standardize on > HashMap unless there is a specific reason to use a different > implementation. The future programmer could be yourself after you have > had time to forget why you used TreeMap. Perhaps the method should be defined to return a SortedMap. If the test says: SortedMap<String, Locale> locales = LocaleHelper.getLocales(); // can't remember the actual name, sorry Any attempt to return a non-Sorted Map, including redefining the method to return a plain Map will be stopped in its tracks by the compiler. Of course, it doesn't stop someone returning a TreeMap with a custom comparator that does something bananas. Java's type system has its limits. tom -- If goods don't cross borders, troops will. -- Fr |