Automated Testing
Про тестування• Тестування не підвищує якість ПЗ,• а сприяє розпізнаванню неправильної  поведінки,• завдяки чому розробник...
Тестування• Починається разом із розробкою• Спосіб: запускаємо і дивимось чи працює• Створюємо допоміжні засоби  – Консоль...
Unit test, визначення•   Код (зазвичай, метод)•   Який викликає інший код•   І після цього перевіряє правильність•   Деяки...
Unit test framework• Виконання тестів  – Одного, декількох, всіх  – Інтеграція з IDE• API для написання тестів• Автоматиза...
Unit test framework• NUnit, MS Test, Xunit, MBUnit, DBUnit• Test runners:  – Visual Studio, NUnit GUI/Console apps,    ReS...
Unit test[TestFixture]public class CalculatorTests{    [Test]    public void Sum_ReturnsCorrectValue()    {        var mat...
Arrange/Act/Assert[TestFixture]public class CalculatorTests{    [Test]    public void Sum_ReturnsCorrectValue()    {      ...
Що тестувати• Код, що містить логіку    private DateTime _startDate;    // doesn’t need to be tested    public DateTime St...
Єдиний assert• Юніт-тест повинен тестувати щось одне• Назва тесту важлива[Test]public void Start_Test(){    var survey = n...
Залежності
DEMO[Test]public void Start_ChangesStateToInProgress(){    var survey = new Survey();    survey.Start();    Assert.AreEqua...
Залежності•   Survey залежить від EmailSender•   Не хочемо відсилати справжні листи•   Створюємо stub вручну•   Створюємо ...
Interaction testing•   Потреба тестувати взаємодії•   Створюємо mock вручну•   Створюємо mock автоматично•   Один mock на ...
Особливості тестів на поведінку• Реалізують  діаграми послідовності  (sequence diagram)• Дозволяють розробляти  “згори вни...
Stubs + mocks• Один тест – один mock• Декілька stubs                 Fakes        Stubs             Mocks         0..*    ...
Короткий підсумок
How unit testing helps• Швидший цикл тестування коду• Коротший фідбек про можливі дефекти• Дефекти дешевші
Плюси тестів•   Кращий код•   Стабільніша нова функціональність•   Більше впевненості у змінах•   Менше регресій•   Коротш...
Різновиди
Види тестів• Юніт• Інтеграційні• Інші
Юніт тести•   Тестують один модуль•   Виконуються виключно в пам’яті•   Не вимагають конфігурації•   Не вимагають DB, FS, ...
Інтеграційні тести• Тестують модулі разом• Можуть мати різну поведінку• В залежності від  – Середовища (FS, DB, AD, OS, .c...
Інтеграційні тести -- Ознаки•   TearDown()•   DateTime.Now•   Thread•   Environment.MachineName•   Database.Save(…)•   Fil...
Структура проекту• Чітке розділення UT та IT
Trustworthy• Юніт-тести – ДОВІРА  – Проходять --> мабуть немає дефекту  – Не проходять --> точно є дефект• Інтеграційні те...
Практики
Якщо в коді помилка, тести     повинні це показувати• Спосіб перевірки – внести помилку і  перевірити, як тести про це спо...
Логіка в юніт-тестах• Asserts in if/switch/for/while• Значно підвищується ймовірність появи  дефекта в тесті• Погіршується...
Дублювання логіки production коду•   Приклад•   Tests last•   Тест не тестує•   Expected hardcoded values
Magic numbers• Приклад• Найпростіші можливі значення• Оголошення і перевірка в тесті
Зміна тестів• Створення:  – У більшості випадків• Видалення:  – Коли тест більше не потрібний• Редагування:  – Для maintai...
Тестувальник знаходить дефект• Пишемо новий тест• Дефект не повинен бути знайдений  тестувальниками знову
Questions
Upcoming SlideShare
Loading in …5
×

Automated testing

1,048 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,048
On SlideShare
0
From Embeds
0
Number of Embeds
524
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Automated testing

  1. 1. Automated Testing
  2. 2. Про тестування• Тестування не підвищує якість ПЗ,• а сприяє розпізнаванню неправильної поведінки,• завдяки чому розробники можуть знайти помилки і виправити їх• Тестування не може довести відсутності дефектів – Лише їх наявність• В будь-якій програмі є дефекти
  3. 3. Тестування• Починається разом із розробкою• Спосіб: запускаємо і дивимось чи працює• Створюємо допоміжні засоби – Консольні програми – Допоміжний UI
  4. 4. Unit test, визначення• Код (зазвичай, метод)• Який викликає інший код• І після цього перевіряє правильність• Деяких припущень• Unit = модуль, компонент• (функція, метод, клас, Unit of Work)
  5. 5. Unit test framework• Виконання тестів – Одного, декількох, всіх – Інтеграція з IDE• API для написання тестів• Автоматизація• Перегляд результатів
  6. 6. Unit test framework• NUnit, MS Test, Xunit, MBUnit, DBUnit• Test runners: – Visual Studio, NUnit GUI/Console apps, ReSharper, TestDriven.Net, Gallio
  7. 7. 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); }}
  8. 8. 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 }}
  9. 9. Що тестувати• Код, що містить логіку private DateTime _startDate; // doesn’t need to be tested public DateTime StartDate { get { return _startDate; } set { _startDate = value; } }
  10. 10. Єдиний assert• Юніт-тест повинен тестувати щось одне• Назва тесту важлива[Test]public void Start_Test(){ var survey = new Survey(); survey.Start(); Assert.AreEqual(SurveyState.InProgress, survey.State); Assert.IsTrue(survey.FinishDate > survey.StartDate);}
  11. 11. Залежності
  12. 12. DEMO[Test]public void Start_ChangesStateToInProgress(){ var survey = new Survey(); survey.Start(); Assert.AreEqual(SurveyState.InProgress, survey.State);}
  13. 13. Залежності• Survey залежить від EmailSender• Не хочемо відсилати справжні листи• Створюємо stub вручну• Створюємо stub автоматично• Все ще тестуємо стан! Assert.AreEqual(SurveyState.InProgress, survey.State);
  14. 14. Interaction testing• Потреба тестувати взаємодії• Створюємо mock вручну• Створюємо mock автоматично• Один mock на тест• Тестуємо не стан, а взаємодію! mockEmailSender.Verify();
  15. 15. Особливості тестів на поведінку• Реалізують діаграми послідовності (sequence diagram)• Дозволяють розробляти “згори вниз”• отримуючи API “нижчих” об’єктів “автоматично”
  16. 16. Stubs + mocks• Один тест – один mock• Декілька stubs Fakes Stubs Mocks 0..* 0..1
  17. 17. Короткий підсумок
  18. 18. How unit testing helps• Швидший цикл тестування коду• Коротший фідбек про можливі дефекти• Дефекти дешевші
  19. 19. Плюси тестів• Кращий код• Стабільніша нова функціональність• Більше впевненості у змінах• Менше регресій• Коротші цикли релізів
  20. 20. Різновиди
  21. 21. Види тестів• Юніт• Інтеграційні• Інші
  22. 22. Юніт тести• Тестують один модуль• Виконуються виключно в пам’яті• Не вимагають конфігурації• Не вимагають DB, FS, AD, Net• Завжди – Повторювано проходять – Або повторювано не проходять – Тому що не залежать від змінних факторів
  23. 23. Інтеграційні тести• Тестують модулі разом• Можуть мати різну поведінку• В залежності від – Середовища (FS, DB, AD, OS, .config) – Порядку виконання – Кількості виконання – Багатопоточності – Повного місяця
  24. 24. Інтеграційні тести -- Ознаки• TearDown()• DateTime.Now• Thread• Environment.MachineName• Database.Save(…)• File.Open(…)
  25. 25. Структура проекту• Чітке розділення UT та IT
  26. 26. Trustworthy• Юніт-тести – ДОВІРА – Проходять --> мабуть немає дефекту – Не проходять --> точно є дефект• Інтеграційні тести – (деколи) НЕДОВІРА – Проходять --> немає дефекту – Не проходять --> можливо дефект
  27. 27. Практики
  28. 28. Якщо в коді помилка, тести повинні це показувати• Спосіб перевірки – внести помилку і перевірити, як тести про це сповіщають
  29. 29. Логіка в юніт-тестах• Asserts in if/switch/for/while• Значно підвищується ймовірність появи дефекта в тесті• Погіршується readability & maintainability
  30. 30. Дублювання логіки production коду• Приклад• Tests last• Тест не тестує• Expected hardcoded values
  31. 31. Magic numbers• Приклад• Найпростіші можливі значення• Оголошення і перевірка в тесті
  32. 32. Зміна тестів• Створення: – У більшості випадків• Видалення: – Коли тест більше не потрібний• Редагування: – Для maintainability/readability – Для швидкості – Коли тест повинен виконуватись по-іншому
  33. 33. Тестувальник знаходить дефект• Пишемо новий тест• Дефект не повинен бути знайдений тестувальниками знову
  34. 34. Questions

×