This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
So, this is what I'm trying to do : I want to write a utility method in my utility class that will accept a vararg of List<Integer> and will return the List with the smallest size. If there are more than one List with the same size, either one is fine. So in my mind, I want to use test files to generate the lists and the testcases like so:
1. lists.csv : contains the lists that will be used for the test
one, two and three are the list names and the integers following them is the content of the list
2. test.csv : contains the lists that will be passed
the first is the expected list name returned by the method and the following strings are the list names passed to the tested method
the method signature is public List<Integer> getSmallestList(List<Integer>... lists).
I'm still confused about how to :
1. create the lists in the fixture from lists.csv and
2. passing the lists to tested method based on test.csv and assert the result
I wouldn't use externalized resources, seems like overkill. There are many ways to go about this sort of thing, each with their own drawbacks and benefits. One way would be as follows:
The drawback here is that the Parameterized test runner will run every @Test annotated method for each set of parameters, so combining this approach with tests that don't depend the input sets (like exception testing) isn't really viable. You'll need additional test classes.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Joined: Feb 01, 2014
The reason I want to use external file is, well, because I like it. haha
It's also because I would want to test more than just 3, but about like 20 or 30 lists and then try different combinations of them to be passed to the tested method.
So, it's just not doable?
Oh sure it's doable, but more complicated than just setting up the fixtures in your test code directly. Also, testing is risk management, you can't possibly test all different input permutations, so choose them carefully and don't test unneccessarily.
Anyway, back to your approach, you have control over the CSV format, which can be simple enough to just use String.split() to parse each line in the file. As for reading the actual file, you'd be best of making it available as a classpath resource. You can use ClassLoader.getResourceAsStream() to get an InputStream to read from.
I would second Jelle's suggestion of not using external files for your test input. If I came across a test like that where it was not immediately obvious what the input and expected output was, and worse required me to go hoking around the source code to find it, I would have a couple of less than complementary words to say about it. Then I would change it to move the data into the test.
Source code is there to be read many many times. So you need to make it as easy to read as you can, which in this case means keeping all related data together in the same file, preferably viewable on the screen all at once without scrolling.