Одиночні чи декілька файлів для тестування одиничного класу?

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

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

Приклад сценарію - клас (називайте його Document), який має два методи: CheckIn і CheckOut. Кожен метод реалізує різні правила тощо, які контролюють їх поведінку. Дотримуючись правила «одне твердження за тест», у мене буде кілька тестів для кожного методу. Я можу розмістити всі тести в одному DocumentTestsкласі з іменами типу " CheckInShouldThrowExceptionWhenUserIsUnauthorizedі" CheckOutShouldThrowExceptionWhenUserIsUnauthorized.

Або я міг би мати два окремі тестові класи: CheckInShouldі CheckOutShould. У цьому випадку мої тестові імена будуть скорочені, але вони будуть організовані, щоб усі тести на конкретну поведінку (метод) були разом.

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

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

Насправді не видно жодної переконливої ​​причини, чому ви розділили б тест для одного класу на кілька тестових класів. Оскільки рушійною ідеєю має бути підтримка згуртованості на рівні класу, вам слід прагнути до цього і на тестовому рівні. Лише деякі випадкові причини:

1. Не потрібно дублювати (і підтримувати кілька версій) коду настройки
2. Простіше запустити всі тести для класу з IDE, якщо вони згруповані в одному тестовому класі
3. Легше вирішити неполадки за допомогою однозначного відображення між тестовими класами та класами.

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

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

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

У випадку, коли різні тести вимагають різко встановлених налаштувань, я бачив, як деякі практикуючі TDD ставлять «кріплення» або «налаштування» в різні класи / файли, але не самі тести.

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

Ось приклад застосування цього підходу до мого оригінального сценарію:

public abstract class DocumentTests : TestBase
{
    [TestClass()]
    public sealed class CheckInShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }

    [TestClass()]
    public sealed class CheckOutShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }
}

Це призводить до появи таких тестів у списку тестів:

DocumentTests+CheckInShould.ThrowExceptionWhenUserIsNotAuthorized
DocumentTests+CheckOutShould.ThrowExceptionWhenUserIsNotAuthorized

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

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

Постарайтеся на хвилину подумати навпаки.

Чому б у вас був лише один тестовий клас на клас? Ви робите тест класу чи тест на одиницю? Ви навіть залежите від занять ?

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

Як ви думаєте про цей псевдо-код:

// check_in_test.file

class CheckInTest extends TestCase {
        /** @test */
        public function unauthorized_users_cannot_check_in() {
                $this->expectException();

                $document = new Document($unauthorizedUser);

                $document->checkIn();
        }
}

Тепер ви безпосередньо не тестуєте checkInметод. Ви замість цього тестуєте поведінку (що означає перевірити на щастя;)), і якщо вам потрібно переробити Documentі розділити її на різні класи, або об'єднати в неї інший клас, ваші тестові файли все ще є когерентними, вони все одно мають сенс, оскільки ви ніколи не змінюєте логіку при рефакторингу, лише структуру.

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

Загалом я б рекомендував думати про тести як про тестування поведінки класу, а не про метод. Тобто для деяких ваших тестів може знадобитися викликати обидва методи в класі, щоб перевірити деяку очікувану поведінку.

Зазвичай я починаю з одного одиничного тестового класу на виробничий клас, але, зрештою, можна розділити цей тестовий клас на кілька тестових класів на основі поведінки, яку вони випробовують. Іншими словами, я б рекомендував не розбивати тестовий клас на CheckInShould та CheckOutShould, а скоріше розбивати його за поведінкою тестованої одиниці.

1. Поміркуйте, що може піти не так

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

Це стає більш цікавим, коли тест виходить з ладу після зміни набагато пізніше. Є дві можливості:

1. Ви серйозно зламали CheckIn(або CheckOut). Знову ж, як однофайлове, так і двофайлове рішення в цьому випадку нормально.
2. Ви змінили і те, CheckInі CheckOut(можливо, їх тести) таким чином, що має сенс для кожного з них, але не для обох разом. Ви порушили злагодженість пари. У такому випадку розбиття тестів на два файли ускладнить розуміння проблеми.

2. Поміркуйте, для чого використовуються тести

Тести служать двом основним цілям:

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

Так?

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