Talk at ITEvent 2011 http://itevent.if.ua/

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

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

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

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

5. Unit test
[TestFixture]
public class CalculatorTests
{
[Test]
public void Sum_ReturnsCorrectValue()
{
var math = new Calculator();
int result = math.Sum(1, 2);
Assert.AreEqual(3, result);
}
}

6. Arrange/Act/Assert
[TestFixture]
public class CalculatorTests
{
[Test]
public void Sum_ReturnsCorrectValue()
{
var math = new Calculator(); // Arrange
int result = math.Sum(1, 2); // Act
Assert.AreEqual(3, result); // Assert
}
}

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

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

9. Unit test framework
• NUnit, MS Test, MBUnit, DBUnit
• JUnit, JWalk, TestNG, DBUnit
• C++test, CppUnit, Google C++ Testing Fx
• PyUnit

10. Continuous integration

11. Continuous integration

12. Залежності

13. DEMO
[Test]
public void Start_ChangesStateToInProgress()
{
var survey = new Survey();
survey.Start();
Assert.AreEqual(SurveyState.InProgress,
survey.State);
}

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

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

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

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

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

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

20. Якості

21. Якості юніт тестів
• Readable
• Maintainable
• Trustworthy

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

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

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

26. Різновиди

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

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

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

30. Інтеграційні тести -- Ознаки
• TearDown()
• DateTime.Now
• Thread
• Environment.MachineName
• Database.Save(…)
• File.Open(…)

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

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

33. Практики

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

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

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

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

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

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

40. Обирайте усвідомлено
• Тестування не безкоштовне
• Надмірність тестів
• Надмірність тестів взаємодій
• 100% покриття не завжди потрібне

41. На що дивитись далі
• Unit testing patterns
• Mocks/stubs/fakes, isolation frameworks
• TDD, Test Driven Development
• Contracts, Contract Driven Development

42. Q&A
Code-driven testing
Олександр Павлишак, 2011
pavlyshak@gmail.com