Я почав писати кілька тестів для мого поточного проекту. Але я насправді не маю досвіду з цим. Я спершу хочу повністю "отримати його", тому наразі я не використовую ні свого ІоК-рамки, ні глузуючої бібліотеки.

Мені було цікаво, чи є щось не так у наданні нульових аргументів конструкторам об'єктів в одиничних тестах. Дозвольте навести приклад коду:

public class CarRadio
{...}


public class Motor
{
    public void SetSpeed(float speed){...}
}


public class Car
{
    public Car(CarRadio carRadio, Motor motor){...}
}


public class SpeedLimit
{
    public bool IsViolatedBy(Car car){...}
}

Ще один приклад автомобільного кодексу (TM), зведений лише до важливих для питання частин. Зараз я написав тест приблизно так:

public class SpeedLimitTest
{
    public void TestSpeedLimit()
    {
        Motor motor = new Motor();
        motor.SetSpeed(10f);
        Car car = new Car(null, motor);

        SpeedLimit speedLimit = new SpeedLimit();
        Assert.IsTrue(speedLimit.IsViolatedBy(car));
    }
}

Тест працює нормально. SpeedLimitпотрібен a Carз a Motor, щоб зробити свою справу. Це взагалі не цікавить CarRadio, тому я вказав нуль для цього.

Мені цікаво, чи об’єкт, що забезпечує правильну функціональність, не будуючи повністю, є порушенням SRP або запахом коду. У мене таке нудотне відчуття, що воно є, але speedLimit.IsViolatedBy(motor)не відчуває себе правильно - обмеження швидкості порушується автомобілем, а не мотором. Можливо, мені просто потрібна інша перспектива для одиничних тестів проти робочого коду, тому що весь намір полягає в тестуванні лише частини цілого.

Чи побудова об'єктів з нульовими одиницями тестів кодовим запахом?

У випадку з наведеним вище прикладом, доцільно, що Carможе існувати без CarRadio. У такому випадку я б сказав, що не тільки прийнятно CarRadioіноді пропускати нуль , я б сказав, що це обов'язково. Ваші тести повинні переконатися, що реалізація Carкласу є надійною та не викидає нульові винятки вказівників, коли таких немає CarRadio.

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

Чи побудова об'єктів з нульовими одиницями тестів кодовим запахом?

Так. Зверніть увагу на визначення C2 запаху коду : "CodeSmell - це натяк на те, що щось може бути не так, а не впевненість".

Тест працює нормально. SpeedLimit потребує Автомобіля з Мотором, щоб зробити свою справу. Це взагалі не цікавить CarRadio, тому я вказав нуль для цього.

Якщо ви намагаєтесь продемонструвати, що speedLimit.IsViolatedBy(car)не залежить від CarRadioаргументу, переданого конструктору, то, мабуть, буде зрозуміліше майбутньому технічному обслуговувачу зробити це обмеження явним шляхом введення тестового подвійного, який не дає змоги тесту, якщо він буде викликаний.

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

• це порушення інкапсуляції (ви випускаєте CarRadioтест, який не використовується, витікає в тест)
• ви виявили принаймні один випадок, коли ви хочете створити Carбез вказівки aCarRadio

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

public Car(IMotor motor) {...}

і тоді той конструктор може вирішити, що робити з тим, що його немаєCarRadio

public Car(IMotor motor) {
    this(null, motor);
}

або

public Car(IMotor motor) {
    this( new ICarRadio() {...} , motor);
}

або

public Car(IMotor motor) {
    this( new DefaultRadio(), motor);
}

тощо.

Йдеться про те, якщо при тестуванні SpeedLimit передавати null щось інше. Ви можете бачити, що тест називається "SpeedLimitTest", і єдиний Assert перевіряє метод SpeedLimit.

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

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

interface IHaveSpeed {
    float speed();
}

class Car implements IHaveSpeed {...}

IHaveSpeed- справді паршиве ім’я; сподіваємось, мова вашого домену покращиться.

Якщо цей інтерфейс на місці, ваш тест для SpeedLimitможе бути набагато простішим

public void TestSpeedLimit()
{
    IHaveSpeed somethingTravelingQuickly = new IHaveSpeed {
        float speed() { return 10f; }
    }

    SpeedLimit speedLimit = new SpeedLimit();
    Assert.IsTrue(speedLimit.IsViolatedBy(somethingTravelingQuickly));
}

Чи побудова об'єктів з нульовими одиницями тестів кодовим запахом?

Ні

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

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

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

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

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

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

class Car
{
   private readonly ICarRadio _carRadio;
   private readonly IMotor _motor;

   public Car(ICarRadio carRadio, IMotor motor)
   {
      if (carRadio == null)
         throw new ArgumentNullException(nameof(carRadio));

      if (motor == null)
         throw new ArgumentNullException(nameof(motor));

      _carRadio = carRadio;
      _motor = motor;
   }
}

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

Сказавши це, це стає проблемою, коли ви зробите дві речі:

1. Програма на інтерфейси замість класів.
2. Використовуйте глузуючий фреймворк (як Moq для C #), щоб вводити знущаються залежності замість нулів.

Отже, для вашого прикладу у вас є:

interface ICarRadio
{
   bool Tune(float frequency);
}

interface Motor
{
   bool SetSpeed(float speed);
}

...
var car = new Car(new Moq<ICarRadio>().Object, new Moq<IMotor>().Object);

Детальніше про використання Moq можна ознайомитись тут .

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

class DummyCarRadio : ICarRadio
{
   ...
}
class DummyMotor : IMotor
{
   ...
}

...
var car = new Car(new DummyCarRadio(), new DummyMotor())

Це не просто гаразд, це добре відома техніка розбиття залежності для отримання застарілого коду в тестову заправку. (Див. "Ефективна робота зі застарілим кодексом" Майкла Пірса.)

Пахне? Добре...

Тест не пахне. Тест робить свою справу. Він оголошує, що "цей об'єкт може бути недійсним, і тестовий код все ще працює правильно".

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

Давайте зробимо крок назад до перших принципів.

Тест одиниці тестує деякий аспект одного класу.

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

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

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

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

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

З огляду на ваш дизайн, я б запропонував: Car складається з набору Features. Особливість може бути CarRadio, або EntertainmentSystemякий може складатися з речей , як CarRadio, і DvdPlayerт.д.

Отже, як мінімум, вам доведеться побудувати а Carз набором Features. EntertainmentSystemі CarRadioбудуть реалізаторами інтерфейсу (Java, C # тощо), public [I|i]nterface Featureі це буде екземпляром композиційного шаблону дизайну.

Тому ви завжди побудували a CarFeatures тест з, і одиничний тест ніколи б не створив Carбез жодного Features. Хоча ви можете розглянути знущання над тим, BasicTestCarFeatureSetщо має мінімальний набір функціональних можливостей, необхідний для вашого найпростішого тесту.

Просто деякі думки.

Джон