Re: Need help designing some JUnit tests
Lew <noone@lewscanon.com> wrote in news:ht4fub$bj8$1@news.albasani.net:
Rhino wrote:
Actually, my getLocales() method is really just a convenience method
that massages the results of Locale.getAvailableLocales() itself.
Just to be sure I'm using the term "convenience method" correctly,
I'm referring to a method I write that uses existing Java API methods
but that combines several lines of code into one or two. For example,
since I
Yep.
Okay, good. At least I know now that I've correctly understood what
_that_ term means. One down and a gazillion to go.... ;-)
prefer my Locales list to be in alphabetical order, I've written
this:
public Map<String, String> getLocales() {
Locale[] listOfLocales = Locale.getAvailableLocales();
Map<String, String> locales = new TreeMap<String, String>();
for (Locale singleLocale : listOfLocales) {
locales.put(singleLocale.toString(), singleLocale.getDisplayName
(locale));
Umm, what is 'locale' in this line? I mean, it's obvious that it's a
'Locale', but what is it?
That 'locale' is an instance variable that the caller can set via a
getInstance(locale) method to set the locale for the class. I'm just
trying to make my code "multilingual" so that a user who is operating in
French or German or whatever will get the output in their language.
}
return locales;
}
Your 'listOfLocales' variable is, perhaps, not necessary.
That idiom also works if you want to retrieve the Locales themselves
based on name:
Map <String, Locale> locales = new TreeMap <String, Locale> ();
for( Locale loc : Locale.getAvailableLocales() )
{
locales.put( loc.getDisplayName(locale), loc );
}
or something like.
I like it :-) I had originally tried to build the map using the locale as
the key but ran up against the fact that Locale is not Comparable so I
did it the way you see in this email. But making the DisplayName the key
and the Locale as the value works fine and is concise to boot so I'll do
it your way.
As such, I don't know how to do a JUnit test on it, specifically how
to generate an expected result that can be compared to my actual
result. It seems self-evident that I have to get my expected result
in a different way than I get the actual result, otherwise, I'm not
proving anything.
Unit tests cannot do everything that the class under test does,
otherwise the unit test class would be the class under test. What
unit tests do is test the "happy path" and various corner cases to
provide a high level of certainty that the tested class will correctly
handle the infinite variety of stuff thrown at it in production. In
other words, a unit test is really a sanity check that takes care of
the most likely issues. If a unit test could prevent all possible
errors, we'd never need logging.
Fair enough.
For your case, you might test that the 'Map' has the same number of
entries as 'getLocales()' has elements and that it correctly returns
the right values for some representative keys.
Okay, that's reasonable. Someone else suggested that I verify that the
en_US is there too, since that's part of the contract from
Locale.getAvailableLocales(). That should be enough for unit testing
then, right?
...
Or is it the case that such a method CAN'T have its accuracy tested
in this way and no such attempt should be made? Is it enough to prove
that the method executes without throwing an exception?
You should go farther than that.
--------------------------------
Scenario 3 - getInstance()
Given a hypothetical class named Fuzz where the constructors and
getInstance() methods are:
private Fuzz() {
// do something
}
private Fuzz(Locale locale) {
// do something
// initialize instance variable for locale
}
public getInstance() {
Lew wrote:
Where is your return value?
This won't even compile.
Rhino wrote:
Sorry, I just hacked that together to save a minute. I probably
should have copied in a compiled example....
Oopsie. (Giggle)
Would the following be adequate as JUnit tests for the
getInstance() methods?
public void testGetInstance() {
Fuzz fuzz = Fuzz.getInstance();
if (!fuzz instanceof Fuzz) fail("Failed to instantiate Fuzz");
}
...
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.
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?
--
Rhino