Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Tomek Kaczanowski - Practical Unit Testing with JUnit and Mockito - 2013.pdf
Скачиваний:
228
Добавлен:
07.03.2016
Размер:
6.59 Mб
Скачать

Chapter 3. Unit Tests with no Collaborators

The equivalent method can be implemented using the $() method.

private static final Object[] getMoney() { return $(

$(10, "USD"), $(20, "EUR")

);

}

To use the $() method in your test code all you have to do is add a static import:

import static junitparams.JUnitParamsRunner.$;

The $() version has some limitations, i.e. it does not allow for accepting null values.

3.6.3. Conclusions

Summing up, the advantages of using parameterized tests over any custom code are the following:

none of one’s own, potentially flawed, logic is introduced (e.g. for loop),

adding another set of arguments is very easy, and does not make the code grow,

a single data-providing method can be used to feed multiple test methods (and can do so across multiple test classes), making the code even more concise,

there is no copy&paste coding, there are no "global" variables, and the DRY principle is faithfully honored,

there is a clear separation between test logic (how the code is expected to work) and test data (what values are tested),

we get more detailed results of the tests’ execution.

3.7. Checking Expected Exceptions

From time to time your code needs to throw an exception. Maybe a method received an unexpected (illegal) value as an argument. Maybe some third-party component that it cooperates with has thrown an exception. Maybe… Anyway, exceptions are a vital part of how your methods behave. They are equally important to the results that are returned. They belong to the interface of your class, and therefore should be tested.

Fortunately, checking for expected exceptions is very easy, these days. The following code snippet illustrates this:

Listing 3.10. Expected exceptions testing pattern

@Test(expected = ExceptionClass.class) public void shouldThrowExceptions() {

//some implementation here which is expected

//to throw an exception of ExceptionClass

}

27

Chapter 3. Unit Tests with no Collaborators

The expected attribute of the @Test annotation specifies exception that is expected to be thrown by this test.

Think of the expected attribute as about another way of writing a try-catch statement, and apply the same rules. In particular do not catch exceptions of the class Exception when something much more specific (e.g. an exception of type the IllegalArgumentException) is expected.

Let us have a look at an example now. We will introduce a change to the Money class. Let its constructor

throw an IllegalArgumentException if:

amount is less than 0,

currency is null or empty.

The updated constructor is displayed in Listing 3.11.

Listing 3.11. Money class constructor with arguments checking

public Money(int amount, String currency) { if (amount < 0) {

throw new IllegalArgumentException( "illegal amount: [" + amount + "]");

}

if (currency == null || currency.isEmpty()) { throw new IllegalArgumentException(

"illegal currency: [" + currency + "]");

}

this.amount = amount; this.currency = currency;

}

Now, we would like to test it7. The test can look as shown in Listing 3.12. It is a parameterized test that you are already familiar with. The use of data-providing methods makes the code very concise and allows for multiple values to be tested without encountering difficulties.

Another thing worth noticing is the lack of assertions in the test methods shown in Listing 3.12. In fact there is no need to write any code to check whether expected exceptions have occurred. JUnit will take care of this, on the basis of information contained within the expected attribute of the @Test annotation. So we can say that in fact there is an implicit assertion, or maybe rather an implicit try-catch statement, added automatically by JUnit.

All of the tests shown in Listing 3.12 are one-liners, but this is only because we don’t need more lines to invoke the constructor of the Money class. Obviously, JUnit does not limit the length of test methods!

7Personally, I feel slightly uneasy about this code-first approach. We shall soon be introducing the test-first technique, and will be adhering to it throughout the rest of the book.

28

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]