Чи слід проводити одиничні тести на відомі дефекти?

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

Відповідь "так", ви повинні написати їх і слід запустити їх.

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

Цікаво, що невдалий тест, який раптово пройде, може бути настільки ж цікавим, як і проходження тесту, який несподівано провалюється.

Я думаю, вам слід провести одиничний тест на поточну поведінку та в коментарях додати правильний тест і правильну поведінку. Приклад:

@Test
public void test() {
  // this is wrong, it should be fixed some time
  Assert.assertEquals(2, new Calculator().plus(2,2));
  // this is the expected behaviour, replace the above test when the fix is available
  // Assert.assertEquals(4, new Calculator().plus(2, 2));
}

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

EDIT: Як сказав Капітан Ман, у великих проектах це не буде виправлено незабаром, але заради документації, оригінальна відповідь краще, ніж нічого.

Кращий спосіб зробити це - дублювання поточного тесту, змусивши клона стверджувати правильну річ, і @Ignoreце повідомлення, наприклад,

@Test
public void test() {
  Assert.assertEquals(2, new Calculator().plus(2,2));
}

@Ignore("fix me, Calculator is giving the wrong result, see ticket BUG-12345 and delete #test() when fixed")
@Test
public void fixMe() {
  Assert.assertEquals(4, new Calculator().plus(2, 2));
}

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

Залежно від інструменту тестування ви можете використовувати omitабо pendфункцію.

Приклад в рубіні:

gem 'test-unit', '>= 2.1.1'
require 'test/unit'

MYVERSION = '0.9.0' #Version of the class you test 


class Test_omit < Test::Unit::TestCase
  def test_omit
    omit('The following assertion fails - it will be corrected in the next release')
    assert_equal(1,2)
  end

  def test_omit_if
    omit_if(MYVERSION < '1.0.0', "Test skipped for version #{MYVERSION}")
    assert_equal(1,2)
  end

end

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

Результатом мого прикладу є:

Loaded suite test
Started
O
===============================================================================
The following assertion fails - it will be corrected in the next release [test_omit(Test_omit)]
test.rb:10:in `test_omit'
===============================================================================
O
===============================================================================
Test skipped for version 0.9.0 [test_omit_if(Test_omit)]
test.rb:15:in `test_omit_if'
===============================================================================


Finished in 0.0 seconds.

2 tests, 0 assertions, 0 failures, 0 errors, 0 pendings, 2 omissions, 0 notifications
0% passed

Тому моя відповідь: Так, реалізуйте тест. Але не плутайте тестер з помилками, якщо ви знаєте, що він вийде з ладу.

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

Відповідь - НЕ ІМХО. Не слід додавати одиничний тест на помилку, поки ви не почнете працювати над виправленням помилки, і тоді не напишете тест (и), який підтверджує помилку, і коли цей тест не завершиться відповідно до звіту про помилку ( s) ви перейдете та виправите фактичний код, щоб пройти тест (и), і помилка буде вирішена, і вона буде закрита після цього.

У моєму світі ми мали б тестовий випадок, у якому QE не вдається, поки помилка не виправляється. І нам, як розробникам, було б відомо про це через несправний ТС та через трекер помилок.

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

Я думаю, що відповідь насправді є, це залежить. Будьте прагматичними щодо цього. Що вас зараз набирає? Може, це свіже у вашому розумі?

Виправляючи помилку, має сенс довести, що вона існує, написавши одиничний тест, який виявляє помилку. Потім ви виправляєте помилку, і тест одиниці повинен пройти.

У вас є час написати тест, який вийшов з ладу? Чи є більш актуальні функції або помилка, які потрібно записати / виправити.

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

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

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