Тестування далеко не завжди буває веселим та цікавим. Цей процес зазвичай досить тривалий і часом сповнений монотонної роботи. Здається, ще зовсім недавно програмісти користувалися стандартним висновком або дебаггером для тестування java класів.

У цій статті я опишу бібліотеку JUnit 4, яка багато в чому спрощує та автоматизує процес написання тестів.

Для демонстрації основних можливостей JUnit Framework, напишемо примітивний клас мовою Java і знущатимемося над ним. Цей клас матиме два методи - знаходження факторіалу невід'ємного числа та суми двох чисел. Крім того, в екземплярі класу буде лічильник викликів методів.

Public class MathFunc ( int calls; public int getCalls() ( return calls; ) public long factorial(int number) ( calls++; if (number 1) ( for (int i = 1; i

Тепер напишемо Unit тести. Для цього створимо клас із деякою кількістю тестових методів. Звичайно, клас може містити і стандартні допоміжні способи. Щоб runner тестів міг визначити, хто є хто, тестові методи необхідно помічати антацією @Test.

Анотації можуть бути проставлені такі параметри:

• expected - вказуємо який виняток буде згенеровано методом (див. приклад нижче);
• timeout - через який час у мілісекундах припинити виконання тесту та зарахувати його як неуспішний.

Якщо ви хочете вказати, що певний тест необхідно пропустити, то позначте його анотацією @Ignore. Хоча можна просто видалити інструкцію @Test.

Буває таке, що для виконання кожного тестового сценарію вам потрібен певний контекст, наприклад, заздалегідь створені екземпляри класів. А після виконання необхідно звільнити зарезервовані ресурси. У цьому випадку вам знадобляться антотації @Before і @After. Метод, помічений @Before, буде виконуватися перед кожним тестовим випадком, а метод, помічений @After - після кожного тестового випадку.

Якщо ж ініціалізацію та звільнення ресурсів потрібно зробити всього один раз – відповідно до та після всіх тестів – то використовуйте пару анотацій @BeforeClass та @AfterClass.

А ось і сам тестовий клас із декількома тестовими сценаріями:

Public class MathFuncTest ( private MathFunc math; @Before public void init() ( math = new MathFunc(); ) @After public void tearDown() ( math = null; ) @Test public void calls() ( assertEquals(0, math .getCalls()), math.factorial(1); assertEquals(1, math.getCalls());math.factorial(1); ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) == 120); ) @Test(expected = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Ignore @Test public void todo() ( assertTrue(math.plus(1, 1) == 3); ) )

Метод calls тестує правильність лічильника дзвінків. Метод factorial перевіряє правильність обчислення факторіалу для деяких стандартних значень. Метод factorialNegative перевіряє, що для негативних значень факотріалу буде кинуто IllegalArgumentException. Метод todo буде проігноровано. Спробуйте прибрати анотацію @Ignore, коли експериментуватимете з кодом.

Метод assertTrue перевіряє, чи є результат виразу вірним. Деякі інші методи, які можуть стати в нагоді:

• assertEquals - очікуваний результат та отриманий результат збігаються;
• assertNull - результатом виразу є null;
• assertNotNull - результат виразу відмінний від null;
• AssertSame - очікуваний і отриманий об'єкт є одним і тим же об'єктом.
• fail – метод генерує виняток AssertionError – додаємо туди, куди не повинен дійти хід виконання програми.

В нашому сучасному світі IDE вміють знаходити та просто запускати тести в проекті. Але що робити, якщо ви хочете запустити їх вручну за допомогою програмного коду. Для цього можна скористатися Runner"ом. Бувають текстовий - junit.textui.TestRunner, графічні версії - junit.swingui.TestRunner, junit.awtui.TestRunner.

Але більш сучасний метод - це використання класу JUnitCore. Додайте наступний метод main у клас MathFuncTest:

Public static void main(String args) throws Exception ( JUnitCore runner = new JUnitCore(); Result result = runner.run(MathFuncTest.class); System.out.println("run tests: " + result.getRunCount()); System.out.println("failed tests: " + result.getFailureCount()); System.out.println("ignored tests: " + result.getIgnoreCount()); System.out.println("success: " + result .wasSuccessful()); )

І результат виконання:

Run tests: 3 failed tests: 0 ignored tests: 1 success: true

У більш ранніх версіях JUnit для написання тестового класу необхідно створити спадкоємця junit.framework.TestCase. Потім необхідно було визначити конструктор, який приймає як параметр String - назву методу - і передати його батьківському класу. Кожен тестовий спосіб повинен був починатися з префіксу test. Для ініціалізації та звільнення ресурсів використовувалися методи setUp та tearDown. Коротше, жах. Ну, а зараз все просто, так.

Ось і все сьогодні. Впевнений, JUnit Framework багато в чому допоможе вам. Коментарі та питання щодо статті вітаються.

JUnit- Бібліотека для модульного тестування програм Java. Створений Кентом Беком та Еріком Гаммою, JUnit належить сім'ї фреймворків xUnit для різних мов програмування, що бере початок у SUnit Кента Бека для Smalltalk. JUnit породив екосистему розширень - JMock, EasyMock, DbUnit, HttpUnit і т.д.

Бібліотека JUnitбула портована іншими мовами, включаючи PHP (PHPUnit), C# (NUnit), Python (PyUnit), Fortran (fUnit), Delphi (DUnit), Free Pascal (FPCUnit), Perl (Test::Unit), C++ (CPPUnit) , Flex (FlexUnit), JavaScript (JSUnit).

JUnit– це Java фреймворк для тестування, тобто тестування окремих ділянок коду, наприклад методів або класів. Досвід, отриманий під час роботи з JUnit, важливий у розробці концепцій тестування програмного забезпечення.

Приклад тесту JUnit

Import org.junit.Test; import junit.framework.Assert; public class MathTest ( @Test public void testEquals() ( Assert.assertEquals(4, 2 + 2); Assert.assertTrue(4 == 2 + 2); ) @Test public void testNotEquals() ( Assert.assertFalse(5 = = 2 + 2);))

Необхідність використання JUnit

JUnit дозволяє у будь-який момент швидко переконатися у працездатності коду. Якщо програма перестав бути дуже простий і включає безліч класів і методів, то її перевірки може знадобитися значний час. Звичайно, цей процес краще автоматизувати. Використання JUnitдозволяє перевірити код програми без значних зусиль та не займає багато часу.

Юніт тестикласів і функцій є своєрідною документацією до того, що очікується в результаті їх виконання. І не просто документацією, а документацією, яка може автоматично перевіряти код на відповідність пред'явленим функціям. Це зручно і часто тести розробляють як разом, так і до реалізації класів. Розробка через тестування – дуже популярна технологія створення серйозного програмного забезпечення.

Види тестування та місце JUnit тестування у класифікації

Тестування програмного забезпечення можна розділити на два види:

• тестування чорної скриньки;
• тестування білої скриньки.

Під час тестування програми як чорної скриньки внутрішня структура програми до уваги не приймається. Все, що має значення, це функціональність, яку програма має забезпечити. При тестуванні програми як ящика до уваги береться внутрішня структура, тобто. клас та методи. Крім цього, тестування можна розділити на чотири рівні:

• юніт тести – тестування окремих ділянок коду;
• інтеграційне тестування - тестування взаємодії та спільної роботи компонентів;
• системне тестування – тестування всієї системи як цілого;
• приймальне тестування – підсумкове тестування готової системи на відповідність вимогам.

Юніт тестування за визначенням є тестуванням білої скриньки.

Використовується unit тестування у двох варіантах – JUnit 3 та JUnit 4. Розглянемо обидві версії, так як у старих проектах досі використовується 3-я версія, яка підтримує Java 1.4.

JUnit 3

Для створення тесту слід успадковувати тест-клас TestCase, перевизначити методи setUp і tearDown за необхідності, та й найголовніше - розробити тестові методи, найменування яких має починатися з абрівіатури "test". При запуску тесту спочатку створюється екземляр тест-класу (для кожного тесту в класі окремий екземпляр класу), потім виконується метод setUp, запускається сам тест, та й на завершення виконується метод tearDown. Якщо будь-який з методів викликає виняток, тест вважається таким, що провалився.

Примітка: методи тестування повинні бути public void, можуть бути static.

Тести складаються з виконання певного коду та перевірок. Перевірки найчастіше виконуються за допомогою класу Assertхоча іноді використовують ключове слово assert.

Як приклад розглянемо утиліту для роботи з рядками, що включає методи для перевірки порожнього рядка та подання послідовності байт у вигляді 16-річного рядка:

Public class JUnit3StringUtilsTest extends TestCase ( private final Map toHexStringData = New HashMap(); protected void setUp() throws Exception ( toHexStringData.put("", New byte); 13, 17, 45, 127)); clear(); ) public void testToHexString() ( for (Iterator iterator = toHexStringData.keySet().iterator(); iterator.hasNext();) ( final String expected = (String)iterator.next(); final byte testData = (byte)toHexStringData.get(expected); final String actual = StringUtils.toHexString(testData); assertEquals(expected, actual); ) ) //... )

Додаткові можливості, TestSuite

JUnit 3 має кілька додаткових можливостей. Наприклад, можна групувати випробування. Для цього необхідно використати клас TestSuite:

Public class JUnit3StringUtilsTestSuite extends TestSuite ( public JUnit3StringUtilsTestSuite() ( addTestSuite(StringUtilsJUnit3Test.class); addTestSuite(OtherTest1.class); addTestSuite(OtherTest2.class); ) )

Можна виконання тесту повторити кілька разів. Для цього використовується RepeatedTest:

Public class JUnit3StringUtilsRepeatedTest extends RepeatedTest ( public JUnit3StringUtilsRepeatedTest() ( super(new JUnit3StringUtilsTest(), 100); ) )

Наслідуючи тест-клас від ExceptionTestCase, можна перевірити код на викид виключення:

Public class JUnit3StringUtilsExceptionTest extends ExceptionTestCase ( public JUnit3StringUtilsExceptionTest(final String name) ( super(name, NullPointerException.class); ) public void testToHexString() ( StringUtils.toHexString(null); ) )

Як видно з прикладів, все досить просто і нічого зайвого - мінімум коду для JUnit тестування.

JUnit 4

JUnit 4 додана підтримка нових можливостей з Java 5.0; Тести можуть бути оголошені за допомогою анотацій. При цьому існує зворотна сумісність із попередньою версією фреймворку. Майже всі розглянуті вище приклади будуть працювати і в JUnit 4 крім RepeatedTest, який відсутній в новій версії.

Які зміни з'явилися в JUnit 4? Розглянемо той самий приклад, але вже з використанням нових можливостей:

Public class JUnit4StringUtilsTest extends Assert ( private final Map toHexStringData = новий HashMap (); @Before public static void setUpToHexStringData() ( toHexStringData.put(", new byte); toHexStringData.put("01020d112d7f", new byte(1,2,13,17,45,127)); toHexStringData.put("10f , new byte(0,-1,-14,17,-128)); //... ) @After public static void tearDownToHexStringData() ( toHexStringData.clear(); ) @Test public void testToHexString() ( for (Map.Entry entry: toHexStringData.entrySet()) ( final byte testData = entry.getValue(); final String expected = entry.getKey(); final String actual = StringUtils.toHexString(testData); assertEquals(expected, actual); ) ) )

Що змінилося в JUnit 4?

• Для спрощення роботи можна успадковуватись від класу Assertхоча це необов'язково.
• Анотація @Beforeозначає методи, які будуть викликані перед виконанням тестів. Методи мають бути public void. Тут зазвичай розміщуються предустановки для тесту, у разі це генерація тестових даних (метод setUpToHexStringData).
• Можна використовувати інструкцію @BeforeClassяка позначає методи, які будуть викликані до створення екземпляра тест-класу; методи повинні бути public static void. Дану інструкцію (метод) має сенс використовувати для тестування у разі, коли клас містить кілька тестів, використовують різні предустановки, або коли кілька тестів використовують одні й самі дані, ніж витрачати час їх створення для кожного тесту.
• Анотація @Afterпозначає методи, викликані після виконання тестів. Методи мають бути public void. Тут розміщуються операції визволення ресурсів після тесту; у нашому випадку – очищення тестових даних (метод tearDownToHexStringData).
• Анотація @AfterClassпов'язана за змістом з @BeforeClassале виконує методи після тестування класу. Як і у випадку з @BeforeClass, методи повинні бути public static void.
• Анотація @Testпозначає тестові методи. Як і раніше, ці методи мають бути public void. Тут розміщуються самі перевірки. Крім того, в даній інструкції можна використовувати два параметри, expected - задає очікуваний виняток і timeout - задає час, після якого тест вважається таким, що провалився.

Приклади використання анотацій із параметрами, JUnit Test:

@Test(expected = NullPointerException.class) public void testToHexStringWrong() ( StringUtils.toHexString(null); ) @Test(timeout = 1000) public void infinity() ( while (true); )

Ігнорування виконання тесту, JUnit Ignore

Якщо один із тестів з якоїсь серйозної причини необхідно відключити, наприклад, тест постійно завершується з помилкою. Виправлення тесту можна відкласти до світлого майбутнього анотуванням @Ignore. Якщо помістити цю інструкцію на клас, то всі тести в цьому класі будуть відключені.

@Ignore @Test(timeout = 1000) public void infinity() ( while (true); )

Правила тастування, JUnit Rule

JUnitдозволяє використовувати певні розробником правила до та після виконання тесту, які розширюють функціонал. Наприклад, є вбудовані правила для завдання таймууту для тесту (Timeout), для завдання очікуваних винятків (ExpectedException), для роботи з тимчасовими файлами (TemporaryFolder) та ін.

Для оголошення правила необхідно створити publicне staticполе типу похідного від MethodRule та анотувати його за допомогою ключового слова Rule.

Public class JUnitOtherTest ( @Rule public final TemporaryFolder folder = New TemporaryFolder(); @Rule public final Timeout timeout = New Timeout(1000); @Rule public final ExpectedException thrown = ExpectedException.none(); @Ignore @ ) ( while (true); ) @Test public void testFileWriting() throws IOException ( final File log = folder.newFile("debug.log"); final FileWriter logWriter = new FileWriter(log); logWriter.append("Hello, "); logWriter.append("World!!!"); logWriter.flush(); logWriter.close(); ) @Test public void testExpectedException() throws IOException ( thrown.expect(NullPointerException.class); StringUtils.toHexString (null); ) )

Набір тестів, JUnit Suite, SuiteClasses

Запуск тесту може бути налаштований за допомогою анотації @RunWith. Тестові класи, які містять у собі тестові методи, можна поєднати у набори тестів (Suite). Наприклад, створено два класи тестування об'єктів: TestFilter, TestConnect. Ці два тестові класи можна об'єднати в один тестовий клас TestWidgets.java:

Package com.objects; import org.junit.runner.RunWith; import org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses (( TestFilter.class, TestConnect.class )) public class TestWidgets ()

Для налаштування тестів використовується анотація @SuiteClasses, в яку включені тестові класи.

Анотація Categories

Анотація Categoriesдозволяє об'єднати тести у категорії (групи). Для цього у тесті визначається категорія @Category, після чого налаштовуються категорії тестів, що запускаються в Suite. Це може виглядати так:

Public class JUnitStringUtilsCategoriesTest extends Assert ( //... @Category (Unit.class) @Test public void testIsEmpty() ( //... ) //... ) @RunWith (Categories.class) @Categories.IncludeCategory ( Unit.class) @Suite.SuiteClasses (( JUnitOtherTest.class, JUnitStringUtilsCategoriesTest.class )) public class JUnitTestSuite ()

Анотація, JUnit Parameterized

Анотація Parameterizedдозволяє використовувати параметризовані тести. Для цього в тест-класі оголошується статичний метод, який повертає список даних, які будуть використані як аргументи конструктора класу.

@RunWith (Parameterized.class) public class JUnitStringUtilsParameterizedTest extends Assert ( private final CharSequence testData; private final boolean expected; public JUnitStringUtilsParameterizedTest(final CharSequence testData, final boolean expected) ( this.testData = test public void testIsEmpty () ( final boolean actual = StringUtils.isEmpty (testData); assertEquals(expected, actual); ) @Parameterized.Parameters public static List