Перевірка працездатності - Значне збільшення кількості об'єктів при використанні JUNIT

Я використовую Junit вперше в проекті, і я зачарований тим, як це змушує мене перебудувати свій код. Одна справа, що я помітив, полягає в тому, що кількість об'єктів, які я створив, щоб перевірити фрагменти коду, значно зростає. Це типово?

Дякую,

Елліотт

2
Можливо, ви можете написати приклад, де це сталося?
додано Автор Raedwald, джерело
Ви говорите про тестові класи або про додаткові класи та об'єкти у вашому звичайному коді?
додано Автор Mark Rotteveel, джерело
Що означає "значне" збільшення? На мій досвід, ви створюєте один клас JUnit для кожного класу "payload", тобто foo.java <-> fooTest.java. Кількість методів в ... Тест може бути досить суттєвим, але це залежить від того, наскільки скрупульозно ви хочете бути.
додано Автор mazaneicha, джерело

3 Відповіді

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

Одним із прикладів може стати метод, який виконує обчислення, оновлює об'єкт і потім зберігає його в базі даних.

public void calculateAndUpdate(Thing t) {
  calculate(t);//quite a complex calculation with mutliple results & updates t
  dao.save(t);
}

Ви можете створити обчислювальний об'єкт, який повертається методом обчислення. Потім метод оновлює об'єкт Thing та зберігає його.

public void calculateAndUpdate(Thing t) {
  Calculation calculation = new Calculator().calculate(t);//does not update t at all
  update(t, calculation);//updates t with the result of calculation
  dao.save(t);//saves t to the database
}

So I've introduced two new objects, a Calculator & Calculation. This allows me to test the result of the calculation without having to have a database available. I can also unit test the update method as well. It's also more functional, which I like :-)

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

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

1
додано
Це може бути статичним, я міг би об'єднати три рядки в одну, але це лише приклад. Початковий метод calculate() виконує розрахунок (який може мати кілька результатів), та оновлюють об'єкт Thing, метою є розмежування цих двох методів. У випадку, коли у вас є кілька результатів, вам знадобиться проміжний клас. Вище це просто ілюстрація загальної техніки.
додано Автор Matthew Farwell, джерело
Чому ваш калькулятор статичний? розрахувати (т). І чому ти повинен мати розрахунок? Не могли б ви просто передати фактичний результат розрахунку, незалежно від того, що це буде для методу оновлення, а не обертати його в об'єкт обчислення?
додано Автор c_maker, джерело

Yes, this is normal.

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

Ви можете прочитати принцип єдиної відповідальності . Дядько Боба також має кілька прикладів повторного факторингу у своїй книзі під назвою Чистий код , де він торкається саме ці точки.

Ще одна річ, коли ви проводите тестування. Ін'єкції залежності є однією з найважливіших речей, яка заощадить вас у великій кількості головного болю, коли мова йде структурування вашого коду. ( І лише для з'ясування, DI не буде необхідним, оскільки ви маєте більше класів, але це допоможе роз'єднати ваші класи ще одне від одного. )

1
додано

залежить від того, які об'єкти ви маєте на увазі. Як правило, ви повинні бути в порядку з використанням макіяжної основи, такі як EasyMock або Mockito, в цьому випадку кількість додаткових класів, необхідних виключно для цілей тестування, має бути набагато меншою. Якщо ви звертаєтесь до додаткових об'єктів у вашому основному вихідному коді, можливо, тест на одиницю допомагає вам реконструювати ваш код, щоб зробити його більш читабельним та багаторазовим, що в будь-якому випадку є гарною ідеєю IMHO :-)

0
додано
ІТ КПІ - Java
ІТ КПІ - Java
436 учасників