Code driven testing -- oleksandr pavlyshak

467
-1

Published on

IT Event 2011 Spring

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
467
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Code driven testing -- oleksandr pavlyshak

  1. 1. Code-driven testing<br />Аудиторія: розробники<br />Олександр Павлишак, 2011<br />pavlyshak@gmail.com<br />
  2. 2. Agenda<br />Поняття Unit test<br />Підміна залежностей, stubs<br />Тестування взаємодій, mocks<br />Якості хороших тестів<br />Unit vs integration testing<br />Практики<br />Метрики<br />
  3. 3. Тестування<br />Починається разом із розробкою<br />Запускаємо і дивимось<br />Створюємо допоміжні засоби<br />Консольні програми<br />Допоміжний UI<br />
  4. 4. Unit test, визначення<br />Код (зазвичай, метод)<br />Який викликає інший код<br />І після цього перевіряє правильність<br />Деяких припущень<br />Unit = модуль, компонент <br />(функція, метод, клас, Unit of Work)<br />
  5. 5. Unit test<br />[TestFixture]<br />publicclassCalculatorTests<br />{<br /> [Test]<br />publicvoidSum_ReturnsCorrectValue()<br /> {<br />var math = newCalculator();<br />int result = math.Sum(1, 2);<br />Assert.AreEqual(3, result);<br /> }<br />}<br />
  6. 6. Arrange/Act/Assert<br />[TestFixture]<br />publicclassCalculatorTests<br />{<br /> [Test]<br />publicvoidSum_ReturnsCorrectValue()<br /> {<br />var math = newCalculator(); // Arrange<br />int result = math.Sum(1, 2); // Act<br />Assert.AreEqual(3, result); // Assert<br /> }<br />}<br />
  7. 7. Єдиний assert/єдиний verify<br />Юніт-тест повинен тестувати щось одне<br />Назва тестуважлива<br />[Test]<br />publicvoidStart_Test()<br />{<br />var survey = newSurvey();<br />survey.Start();<br />Assert.AreEqual(SurveyState.InProgress, survey.State);<br />Assert.IsTrue(survey.FinishDate > survey.StartDate);<br />}<br />
  8. 8. Unit test framework<br />Виконання тестів<br />Одного, декількох, всіх<br />Інтеграція з IDE<br />API для написання тестів<br />Автоматизація<br />Перегляд результатів<br />
  9. 9. Unit test framework<br />NUnit, MS Test, MBUnit, DBUnit<br />JUnit, JWalk, TestNG, DBUnit<br />C++test, CppUnit, Google C++ Testing Fx<br />PyUnit<br />
  10. 10. Continuous integration<br />
  11. 11. Continuous integration<br />
  12. 12. Залежності<br />
  13. 13. DEMO<br />[Test]<br />publicvoidStart_ChangesStateToInProgress()<br />{<br />var survey = newSurvey();<br />survey.Start();<br />Assert.AreEqual(SurveyState.InProgress,<br />survey.State);<br />}<br />
  14. 14. Залежності<br />Survey залежить від EmailSender<br />Не хочемо відсилати справжні листи<br />Створюємо stub вручну<br />Створюємо stub автоматично<br />Все ще тестуємо стан!Assert.AreEqual(SurveyState.InProgress, survey.State);<br />
  15. 15. Interaction testing<br />Потреба тестувати взаємодії<br />Створюємо mock вручну<br />Створюємо mock автоматично<br />Один mock на тест<br />Тестуємо не стан, а взаємодію!mockEmailSender.Verify();<br />
  16. 16. Stubs + mocks<br />Один тест – один mock<br />Декілька stubs<br />Fakes<br />Stubs 0..*<br />Mocks 0..1<br />
  17. 17. Короткий підсумок<br />
  18. 18. How unit testing helps<br />Швидший цикл тестування коду<br />Коротший фідбек про можливі дефекти<br />Дефекти дешевші<br />
  19. 19. Плюси тестів<br />Кращий код<br />Стабільніша нова функціональність<br />Більше впевненості у змінах<br />Менше регресій<br />Коротші цикли релізів<br />
  20. 20. Якості<br />
  21. 21. Якості юніт тестів<br />Readable<br />Maintainable<br />Trustworthy<br />
  22. 22. Readable<br />Легко зрозуміти, що відбувається в тесті<br />Який код тестується<br />Які передумови<br />Які припущення перевіряються<br />Що тестує тест<br />Простий код тесту<br />
  23. 23. Trustworthy<br />Релевантні до помилок<br />Стабільно (не) проходять<br />Немає конфліктуючих тестів<br />Справді тестують<br />
  24. 24.
  25. 25. Maintainable<br />Тести легко реагують на зміни<br />Не вимагають конфігурації<br />Не залежать від інших тестів<br />Простий код тесту<br />
  26. 26. Різновиди<br />
  27. 27. Види тестів<br />Юніт<br />Інтеграційні<br />Інші<br />
  28. 28. Юніт тести<br />Тестують один модуль<br />Виконуються виключно в пам’яті<br />Не вимагають конфігурації<br />Не вимагають DB, FS, AD, Net<br />Завжди<br />Повторювано проходять<br />Або повторювано не проходять<br />Тому що не залежать від змінних факторів<br />
  29. 29. Інтеграційні тести<br />Тестують модулі разом<br />Можуть мати різну поведінку<br />В залежності від<br />Середовища (FS, DB, AD, OS, .config)<br />Порядку виконання<br />Кількості виконання<br />Багатопоточності<br />Повного місяця<br />
  30. 30. Інтеграційні тести -- Ознаки<br />TearDown() <br />DateTime.Now<br />Thread<br />Environment.MachineName<br />Database.Save(…)<br />File.Open(…)<br />
  31. 31. Mixing<br />Чітке розділення UT та IT<br />
  32. 32. Trustworthy<br />Юніт-тести – ДОВІРА<br />Проходять --> мабуть немає дефекту<br />Не проходять --> точно є дефект<br />Інтеграційні тести – (деколи) НЕДОВІРА<br />Проходять --> немає дефекту<br />Не проходять --> можливо дефект <br />
  33. 33. Практики<br />
  34. 34. Логіка в юніт-тестах<br />Asserts in if/switch/for/while<br />Значно підвищується ймовірність появи дефекта в тесті<br />Погіршується readability & maintainability<br />
  35. 35. Дублювання логіки production коду<br />Приклад<br />Tests last<br />Тест не тестує<br />Expected hardcoded values<br />
  36. 36. Magic numbers<br />Приклад <br />Найпростіші можливі значення<br />Оголошення і перевірка в тесті<br />
  37. 37. Tests first<br />Тест<br />Не компілюється/не проходить<br />Реалізація <br />Тест проходить<br />Покращення<br />Впевненість, що тести не містять баги<br />
  38. 38. Зміна тестів<br />Створення:<br />У більшості випадків<br />Видалення:<br />Коли тест більше не потрібний<br />Редагування:<br />Для maintainability/readability<br />Для швидкості<br />Коли тест повинен виконуватись по-іншому<br />
  39. 39. Тестувальник знаходить дефект<br />Новий тест<br />Не повинен бути знайдений тестувальниками знову<br />
  40. 40. Що міряти<br />Кількість регресій<br />Час виправлення дефектів<br />Метрики якості коду<br />People feedback<br />Покриття (coverage)<br />
  41. 41. Покриття (test coverage)<br />
  42. 42. Покриття – способи перевірки<br />«Диверсія» в продакшн коді<br />Автоматизовані засоби<br />
  43. 43. Branch coverage<br />
  44. 44. Покриття<br />Не завжди працює<br />0%<br />1-2%<br />~50%<br />>95%<br />
  45. 45. Обирайте усвідомлено<br />Тестування не безкоштовне<br />Надмірність тестів<br />Надмірність тестів взаємодій<br />100% покриття не завжди потрібне<br />
  46. 46. На що дивитись далі<br />Unit testing patterns<br />Mocks/stubs/fakes, isolation frameworks<br />TDD, Test Driven Development<br />Contracts, Contract Driven Development<br />
  47. 47. Q&A<br />Code-driven testing<br />Олександр Павлишак, 2011<br />pavlyshak@gmail.com<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×