I've been learning Java just for a bit, so please advise how exception throwing test should look like in this case?
I have following Gambling Machine Class. And then 2 tests for it. I do not really know what should follow the "Integer" in second method (shouldThrowWhenNumbersOutOfRange). Could you please advise as to the exact syntax?
public class GamblingMachine {
public int howManyWins(Set<Integer> userNumbers) throws InvalidNumbersException {
validateNumbers(userNumbers);
Set<Integer> computerNumbers = generateComputerNumbers();
int count = 0;
for (Integer number : userNumbers) {
if (computerNumbers.contains(number)) {
count++;
}
}
return count;
}
private void validateNumbers(Set<Integer> numbers) throws InvalidNumbersException {
if (numbers.size() != 6) {
throw new InvalidNumbersException();
}
if (numbers.stream().anyMatch(number -> number < 1 || number > 49)) { //anyMatch-function to check whether any element in list satisfy given condition
throw new InvalidNumbersException();
}
}
private Set<Integer> generateComputerNumbers() {
Set<Integer> numbers = new HashSet<>();
Random generator = new Random();
while(numbers.size() < 6) {
numbers.add(generator.nextInt(49) + 1);
}
return numbers;
}
}
private GamblingMachine machine = new GamblingMachine();
#ParameterizedTest
#NullAndEmptySource
public void shouldThrowWhenNumbersEmpty(Set<Integer> numbers) throws InvalidNumbersException {
Assertions.assertThrows(NumberFormatException.class, () -> {
Integer.parseInt(" ");
});
}
#ParameterizedTest
#CsvFileSource(resources ="/numbersOutOfRange.cvs", numLinesToSkip = 1)
public void shouldThrowWhenNumbersOutOfRange(Set<Integer> numbers) throws InvalidNumbersException {
Assertions.assertThrows(NumberFormatException.class, () -> {
Integer. //how code should look like here?
});
}
The point of a test is to, you know, test something. Your shouldThrowWhenNumbersEmpty test doesn't do that (well, it tests that Integer.parseInt(" ") throws something. It does, of course. You... don't have to test the core libraries).
In other words, your gambling machine tests need to be calling some stuff from your GamblingMachine class. The idea is to test GamblingMachine. Not to test Integer.parseInt.
It's also a bizarre test: Why in the blazes is shouldThrowWhenNumbersEmpty parameterized? I assume the point of that test is: "Ensure that the gambling machine works as designed when passing an empty set of numbers in, specifically, the part of the design that states that an InvalidNumbersException is thrown if you do that".
Which is done with something like:
#Test
public void shouldThrowWhenNumbersEmpty() {
Assertions.assertThrows(InvalidNumbersException.class, () -> {
Set<Integer> empty = Set.of();
machine.howManyWins(empty);
});
}
Parameterized tests are a fairly exotic concept. Your test setup appears to be falling into a trap: It appears to be set up that you repeat all the logic that is already in your gamblingmachine class, to then apply this logic to the incoming (parameterized) data, figure out what your gambling machine ought to be doing, and then double check its work.
That's not how you should write tests. Tests focus on a specific result. Parameterized tests can make sense, but only if the stuff you have to do for any given input is roughly the same. For example:
Good use of parameterized testing
You have a csv file containing a bunch of lines, each of which has 6 rolls + the correct answer. Your parameterized test treats each line the same: Call howManyWins using the 6 rolls as input, then check that howManyWins returns the expected value.
Bad use of parameterized testing
You have a csv file containing a bunch of lines, each of which has 6 rolls. Your parameterized test will calculate the right result for the rolls, then invoke gambling machine, and check that the gambling machine gives the same answer as what you calculated.
This is bad: You're just repeating the code. It also means your test code is itself doing more than the very basics (it's doing a bunch of business logic), thus raising the question: Who tests your test, then?
Both of your test methods seem like they should NOT be parameterized, unless that csv also contains results.
Related
Right now, I have around 107 test input cases for my interpreter, and I have my JUnit tester set up to manually handle each case independently so as to not lump them all together. That is, if I use a loop to iterate over the test files as such
for (int i = 0; i < NUM_TESTS; i++) {
String fileName = "file_" + (i + 1) + ".in";
testFile(fileName);
}
JUnit will create one giant test result for all 107 tests, meaning if one fails, the entire test fails, which I don't want. As I said, right now I have something like
#Test
public static void test001() {
testFile("file1.in");
}
#Test
public static void test002() {
testFile("file2.in");
}
While this works, I imagine there's a much better solution to get what I'm after.
You can use #ParameterizedTest with #MethodSource annotations.
For exemple :
#ParameterizedTest
#MethodSource("fileNameSource")
void test(final String fileName) {
testFile(fileName);
}
private static Stream<String> fileNameSource() {
return IntStream.range(0,NUM_TESTS).mapToObj(i -> "file_" + (i + 1) + ".in");
}
Check the documentation at https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests
For each params returned by fileNameSource(), the corresponding test will be considered as a different case.
You have to define own structure based on your need,
one way to define your input to json file in like list of values as below.
{
[
"value1",
"value2"
]
}
Read this value when you test case execute with the help of object mapper.
objectMapper.readValue(fixture("filePathName.json"),CustomInput.class);
Where CustomInput would be something like below.
public class CustomInput {
List<String> values;
}
You can keep increase & decrease your inputs in json.
This question already has answers here:
How to write a Unit Test?
(5 answers)
Closed 4 years ago.
Below is the code I want to test
public class EPATestMode {
public static final int INVALID_MPG = -1;
private int odometerAtReset;
public EPATestMode() {
odometerAtReset = 0;
}
public void resetReadings(int milesDriven) {
// Use the current mileage as the new baseline
odometerAtReset = milesDriven;
}
public double mpg(int currentOdometer, int gallonsBurnt) {
if (gallonsBurnt == 0) {
return INVALID_MPG;
} else {
int milesDriven = currentOdometer - odometerAtReset;
return milesDriven / gallonsBurnt;
}
}
}
This is my first testcase I want to do , on the instance variable INvalid MPG but when I do this , there is a line crossing out "assertEquals". Very confused about this.(Also new to JUnit testing)
#Test
public void testInvalidMpg() {
EPATestMode MpgTest = new EPATestMode();
double results=MpgTest.INVALID_MPG;
assertEquals(results,-1)
}
You don't state your environment, but most likely it behaves similar to Eclipse (maybe it is Eclipse?) in that a line through the code is an indication that you're using a deprecated API. In this case, if you go to the Junit API documentation, you'll see that assertEquals for doubles like you are calling is deprecated in favor of one that includes a delta. API
The idea is that floating point numbers are inherently inexact, and so comparing them is inexact at best. You need to also include a delta so that you can indicate how far apart the numbers can be and still be acceptable.
So basically you want:
assertEquals(results, -1, .000001); // For example.
On a side note, I understand that you're just trying to wrap your head around this - and consequently you're probably trying to come up with a simple test just to get "something working". But tests like that - where you compare a class constant to see if it's what you input - aren't particularly useful. I would be more inclined to test to make sure that supplying 0 as your "gallons burnt" returns the proper "INVALID_MPG" constant.
Line crossing out means the method is deprecated. http://junit.sourceforge.net/javadoc/org/junit/Assert.html#assertEquals(double, double)
The new method to use is below
public static void assertEquals(double expected,
double actual,
double delta)
The delta is how much difference the actual and expected can have.
I have the following code, and I dont know how to test it.
I was trying to access the count contD++, and if i have 3 negatives.
I cant test it with something like this assertEquals(contD,3)
public void listarD() {
int contD = 0;
for(int i=0; i< clientes.length; i++) {
if(clientes[i].getSaldo() < 0) {
System.out.println(
"Cliente: " + clientes[i].getNombre() +
". Saldo: " + clientes[i].getSaldo());
contD++;
}
}
if (contD == 0) {
System.out.println("No hay descubiertos :D");
}
else {
System.out.println("TOTAL DESCUBIERTOS: " + contadorDescubiertos + " clientes");
}
}
Correct way would be to extract a method that calculates your contD value and test it.
public void listarD() {
int contD = calculateContD();
if (contD == 0) {
...
}
}
And then you can test this calculateContD() method.
A well designed method should be easy to test, the fact that you cannot test your method is an evidence of a design flaw.
Some suggestions:
Make the result of the method verifiable (That could imply that it's
no longer void).
Leave the output on a permanent storage, like disk
or database.
There is one way you could theoretically test this: one can change the object behind System.out.
So, theoretically, you could put a "special" OutputStream into System.out; run your void method; and then check that the messages you would expect ... show up in that stream of yours.
But that simply makes no (t much) sense: you see, in the real world, you rarely do print to system.out. In the real world, your methods either
do return a value
make calls on other objects
change some internal state of the enclosing object/class
Thus: in the real world, you write tests that care about such kind of events.
So, as you figured yourself; the real answer is to change the behavior of your void method; by returning the value it computed already!
In general, a function that can only be verified by human eyes is not a good design. Callers would never know what happened after they call your function. Either a return value or an exception for denoting the result is better than nothing.
While Using TDD I found myself needing to test a constant (final) hashmap which contains lookup values (PLEASE SEE REASON WHY THIS WAS THE CASE UNDER UPDATE)
See below
private static final Map<Integer,String> singleDigitLookup = new HashMap<Integer, String>(){{
put(0,"Zero");put(1,"One");put(2,"Two");put(3,"Three");put(4,"Four");put(5,"Five");put(6,"Six");put(7,"Seven");
put(8,"Eight");put(9,"Nine");
}};
With TDD its stressed to test one thing at a time so i started calling my class verifying the validity of each of the elements as below.
TEST STYLE 1
#Test
public void whenWordIsOneThenReturn1(){
assertEquals(1, WordToIntegerConverter.toInteger("One"));
}
after writing the third test I thought it was pretty ridiculous and created a temporary lookup with the reverse key value pairs and began calling in a loop to test as below.
TEST STYLE 2
#Test
public void whenWordIsZeroThroughNineReturnIntegerConversion(){
HashMap<Integer, String> lookup = new HashMap<Integer, String>(){{
put(0,"Zero");put(1,"One");put(2,"Two");put(3,"Three");put(4,"Four");put(5,"Five");
put(6,"Six");put(7,"Seven");put(8,"Eight");put(9,"Nine");
}};
for(int i = 0; i < 10; i++) {
assertEquals(i, WordToIntegerConverter.toInteger(lookup.get(i)));
}
}
My Question is this; is it better to use style 1 for unit testing or is it better to use style 2.
I see pros and cons for both. for example style 1 is very concise, test only one thing and easier to understand. cons for style 1 besides doing a ton of typing the Test suite will blow up with many trivial test. Pros for style 2 is less unit tests. cons for style 2 has a bit of complexity and may be testing more than one thing but I would argue its only testing one thing the validity of the constant hashmap.
UPDATE
I've received a decent amount of blowback from this question so let me further explain. Its not the constant I care about per se but validating the different cases of my code. This Was a practice problem (Practicing TDD Via Katas) not production code. The problem was converting numbers to words so what I care about in my unit testing is ensuring I could properly handle the different possible numbers. There were other constants that I didn't include for example constant storing teen numbers (11, 12, 13...) and tensDigits(20, 30, 40...). Its fairly easy to make a typo here.
Approach #1 gets the job done, just with an obnoxious amount of cut-n-pasting. Approach #2 fixes that, but at the expense that the tests aren't independent: if one test fails the following ones don't run. Fixing one test just to find a bunch of new ones now fail is pretty annoying. You can improve on this by making a parameterized test, here's an example from junit's wiki:
#RunWith(Parameterized.class)
public class FibonacciTest {
#Parameters
public static Collection<Object[]> data() {
return Arrays.asList(new Object[][] {
{ 0, 0 }, { 1, 1 }, { 2, 1 }, { 3, 2 }, { 4, 3 }, { 5, 5 }, { 6, 8 }
});
}
private int fInput;
private int fExpected;
public FibonacciTest(int input, int expected) {
fInput= input;
fExpected= expected;
}
#Test
public void test() {
assertEquals(fExpected, Fibonacci.compute(fInput));
}
}
The parameterized test includes a collection of input/expected-output pairs, for each pair the input and output get passed into the constructor call for the test and the test method is called on the new test instance. The looping is kept in the test framework and out of the test, and each test succeeds or fails independently of the others.
I'm practicing unit testing on the methods of the Java Period class. The method minusDays looks like this:
public Period minusDays(long daysToSubtract) {
return (daysToSubtract == Long.MIN_VALUE ? plusDays(Long.MAX_VALUE).plusDays(1) : plusDays(-daysToSubtract));
My unit test looks like this:
#Test
public void testMinusDays ()
{
Period x = Period.of(1,1,2);
Period y = Period.of(1,1,1);
Assert.assertEquals(y, x.minusDays(1));
}
And the problem is I'm getting 50% branch coverage and don't know which parts of the if else I'm testing because I can't follow it.
First Step: If ? : is too confusing, replace it with an equal if condition:
public Period minusDays(long daysToSubtract) {
if (daysToSubtract == Long.MIN_VALUE) {
return plusDays(Long.MAX_VALUE).plusDays(1);
}
return plusDays(-daysToSubtract);
}
And now you know what you are missing. You are tesing for daysToSubtract == 1, but not the possibility daysToSubtract == Long.MIN_VALUE, in other words you are only testing one one of two cases, which makes 50%.
you have to write a test with x.minusDay(Long.MIN_VALUE) and a test with another value. after that you should have 100%