Code driven testing -- oleksandr pavlyshak

Code-driven testingАудиторія: розробникиОлександр Павлишак, 2011pavlyshak@gmail.com

AgendaПоняття Unit testПідміна залежностей, stubsТестування взаємодій, mocksЯкості хороших тестівUnit vs integration testingПрактикиМетрики

ТестуванняПочинається разом із розробкоюЗапускаємо і дивимосьСтворюємо допоміжні засобиКонсольні програмиДопоміжний UI

Unit test, визначенняКод (зазвичай, метод)Який викликає інший кодІ після цього перевіряє правильністьДеяких припущеньUnit = модуль, компонент (функція, метод, клас, Unit of Work)

Unit test[TestFixture]publicclassCalculatorTests{ [Test]publicvoidSum_ReturnsCorrectValue() {var math = newCalculator();int result = math.Sum(1, 2);Assert.AreEqual(3, result); }}

Arrange/Act/Assert[TestFixture]publicclassCalculatorTests{ [Test]publicvoidSum_ReturnsCorrectValue() {var math = newCalculator(); // Arrangeint result = math.Sum(1, 2); // ActAssert.AreEqual(3, result); // Assert }}

Єдиний assert/єдиний verifyЮніт-тест повинен тестувати щось однеНазва тестуважлива[Test]publicvoidStart_Test(){var survey = newSurvey();survey.Start();Assert.AreEqual(SurveyState.InProgress, survey.State);Assert.IsTrue(survey.FinishDate > survey.StartDate);}

Unit test frameworkВиконання тестівОдного, декількох, всіхІнтеграція з IDEAPI для написання тестівАвтоматизаціяПерегляд результатів

Unit test frameworkNUnit, MS Test, MBUnit, DBUnitJUnit, JWalk, TestNG, DBUnitC++test, CppUnit, Google C++ Testing FxPyUnit

DEMO[Test]publicvoidStart_ChangesStateToInProgress(){var survey = newSurvey();survey.Start();Assert.AreEqual(SurveyState.InProgress,survey.State);}

ЗалежностіSurvey залежить від EmailSenderНе хочемо відсилати справжні листиСтворюємо stub вручнуСтворюємо stub автоматичноВсе ще тестуємо стан!Assert.AreEqual(SurveyState.InProgress, survey.State);

Interaction testingПотреба тестувати взаємодіїСтворюємо mock вручнуСтворюємо mock автоматичноОдин mock на тестТестуємо не стан, а взаємодію!mockEmailSender.Verify();

Stubs + mocksОдин тест – один mockДекілька stubsFakesStubs 0..*Mocks 0..1

Короткий підсумок

How unit testing helpsШвидший цикл тестування кодуКоротший фідбек про можливі дефектиДефекти дешевші

Плюси тестівКращий кодСтабільніша нова функціональністьБільше впевненості у змінахМенше регресійКоротші цикли релізів

Якості юніт тестівReadableMaintainableTrustworthy

ReadableЛегко зрозуміти, що відбувається в тестіЯкий код тестуєтьсяЯкі передумовиЯкі припущення перевіряютьсяЩо тестує тестПростий код тесту

TrustworthyРелевантні до помилокСтабільно (не) проходятьНемає конфліктуючих тестівСправді тестують

Code driven testing -- oleksandr pavlyshak

MaintainableТести легко реагують на зміниНе вимагають конфігураціїНе залежать від інших тестівПростий код тесту

Види тестівЮнітІнтеграційніІнші

Юніт тестиТестують один модульВиконуються виключно в пам’ятіНе вимагають конфігураціїНе вимагають DB, FS, AD, NetЗавждиПовторювано проходятьАбо повторювано не проходятьТому що не залежать від змінних факторів

Інтеграційні тестиТестують модулі разомМожуть мати різну поведінкуВ залежності відСередовища (FS, DB, AD, OS, .config)Порядку виконанняКількості виконанняБагатопоточностіПовного місяця

Інтеграційні тести -- ОзнакиTearDown() DateTime.NowThreadEnvironment.MachineNameDatabase.Save(…)File.Open(…)

MixingЧітке розділення UT та IT

TrustworthyЮніт-тести – ДОВІРАПроходять --> мабуть немає дефектуНе проходять --> точно є дефектІнтеграційні тести – (деколи) НЕДОВІРАПроходять --> немає дефектуНе проходять --> можливо дефект

Логіка в юніт-тестахAsserts in if/switch/for/whileЗначно підвищується ймовірність появи дефекта в тестіПогіршується readability & maintainability

Дублювання логіки production кодуПрикладTests lastТест не тестуєExpected hardcoded values

Magic numbersПриклад Найпростіші можливі значенняОголошення і перевірка в тесті

Tests firstТестНе компілюється/не проходитьРеалізація Тест проходитьПокращенняВпевненість, що тести не містять баги

Зміна тестівСтворення:У більшості випадківВидалення:Коли тест більше не потрібнийРедагування:Для maintainability/readabilityДля швидкостіКоли тест повинен виконуватись по-іншому

Тестувальник знаходить дефектНовий тестНе повинен бути знайдений тестувальниками знову

Що мірятиКількість регресійЧас виправлення дефектівМетрики якості кодуPeople feedbackПокриття (coverage)

Покриття (test coverage)

Покриття – способи перевірки«Диверсія» в продакшн кодіАвтоматизовані засоби

Code driven testing -- oleksandr pavlyshak

More Related Content

Code driven testing -- oleksandr pavlyshak