Однак з повідомленням результати тестування стають набагато приємніше при читанні.
Розробники зазвичай пишуть юніт-тести тільки для передбачених розробником / архітектором / документацією / etc варіантів поведінки функції. для
StringUtils. fromDouble () документація вказує що функція повинна перетворити Цисла з плаваючою комою в рядок.
Юніт-тест цієї функції покриває тільки описаний функціонал. Мета юніт-тестування - переконатися, що функція працює правильно, а не шукати умови,
в яких вона працює неправильно.
Більш того, сам юніт-тест вже є короткою і зрозумілою документацією до функції. У чотирьох рядках чітко і однозначно написано, як поводиться функція: повертає новий строковий об'єкт, значення якого є переданим їй числом з плаваючою комою, записане в десятковій системі числення.
А найголовніший бонус юніт-тестування, це фіксація поведінки коду. Ви знаєте, прямо зараз, що функція поводиться певним чином. І код, який її використовує, покладається на цю поведінку. Якщо Коли ви захочете змінити цю функцію, юніт-тест буде вам гарантувати, що
поведінку функції залишилося таким же (або тест провалиться). Отже решті код не помітить зміни реалізації функції, а це значить, що з цього моменту ви можете спокійній міняти будь-яку частину коду: юніт-тести не дозволять вам що-небудь зламати.
Другий юніт-тест
Наступний юніт-тест напишемо для зворотного функції перетворення рядка в число з плаваючою комою:
Це оцень проста функція і тому тест теж дуже простий: вхідний значення, еталонне значення і порівняння з результатом.Обично при написанні таких простих тестів явно не заводять змінні для значень, а пишуть їх прямо в assert * функції.
Однак у assertEquals в цьому тесті з'явився додатковий параметр! Справа в тому, що порівнювати числа з плаваючою комою безпосередньо один з одним не можна, так як вони не мають точного двійкового представлення. Зазвичай числа порівнюються з деякою погрішністю: можна сказати що 3.1415000000001 еквівалентно
3.1415000000002 з похибкою до 0.000000000001. І саме ця похибка передається в третій параметр assertEquals для числі з плаваючою комою. Друга частина тесту очевидна - перевіряється що для переданого null повертається NaN.
Третій юніт-тест
junit. framework. AssertionFailedError. expected. <[ Ljava. lang. String ; @61b383e9> but was. <[ Ljava. lang. String ; @5099681b>
Тому в JUnit передбачена спеціальна функція для порівняння масивів assertArrayEquals, яка порівнює еквівалентність кожного елемента обох масивів один з одним. Зрозуміло порівнюються між собою елементи з однаковою позицією в масиві і масиви різної довжини відразу визнаються не еквівалентними. Треба відзначити що зворотної функції для assertArrayEquals не передбачено.
Тест для останньої залишилася функції (joinArray) я пропоную написати самостійно.
Приклад тесту, для порівняння: