Your SlideShare is downloading. ×
0
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Code driven testing -- oleksandr pavlyshak
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Code driven testing -- oleksandr pavlyshak

455

Published on

IT Event 2011 Spring

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
455
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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]
    publicclassCalculatorTests
    {
    [Test]
    publicvoidSum_ReturnsCorrectValue()
    {
    var math = newCalculator();
    int result = math.Sum(1, 2);
    Assert.AreEqual(3, result);
    }
    }
  • 6. Arrange/Act/Assert
    [TestFixture]
    publicclassCalculatorTests
    {
    [Test]
    publicvoidSum_ReturnsCorrectValue()
    {
    var math = newCalculator(); // Arrange
    int result = math.Sum(1, 2); // Act
    Assert.AreEqual(3, result); // Assert
    }
    }
  • 7. Єдиний assert/єдиний verify
    Юніт-тест повинен тестувати щось одне
    Назва тестуважлива
    [Test]
    publicvoidStart_Test()
    {
    var survey = newSurvey();
    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]
    publicvoidStart_ChangesStateToInProgress()
    {
    var survey = newSurvey();
    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 0..*
    Mocks 0..1
  • 17. Короткий підсумок
  • 18. How unit testing helps
    Швидший цикл тестування коду
    Коротший фідбек про можливі дефекти
    Дефекти дешевші
  • 19. Плюси тестів
    Кращий код
    Стабільніша нова функціональність
    Більше впевненості у змінах
    Менше регресій
    Коротші цикли релізів
  • 20. Якості
  • 21. Якості юніт тестів
    Readable
    Maintainable
    Trustworthy
  • 22. Readable
    Легко зрозуміти, що відбувається в тесті
    Який код тестується
    Які передумови
    Які припущення перевіряються
    Що тестує тест
    Простий код тесту
  • 23. Trustworthy
    Релевантні до помилок
    Стабільно (не) проходять
    Немає конфліктуючих тестів
    Справді тестують
  • 24.
  • 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. Tests first
    Тест
    Не компілюється/не проходить
    Реалізація
    Тест проходить
    Покращення
    Впевненість, що тести не містять баги
  • 38. Зміна тестів
    Створення:
    У більшості випадків
    Видалення:
    Коли тест більше не потрібний
    Редагування:
    Для maintainability/readability
    Для швидкості
    Коли тест повинен виконуватись по-іншому
  • 39. Тестувальник знаходить дефект
    Новий тест
    Не повинен бути знайдений тестувальниками знову
  • 40. Що міряти
    Кількість регресій
    Час виправлення дефектів
    Метрики якості коду
    People feedback
    Покриття (coverage)
  • 41. Покриття (test coverage)
  • 42. Покриття – способи перевірки
    «Диверсія» в продакшн коді
    Автоматизовані засоби
  • 43. Branch coverage
  • 44. Покриття
    Не завжди працює
    0%
    1-2%
    ~50%
    >95%
  • 45. Обирайте усвідомлено
    Тестування не безкоштовне
    Надмірність тестів
    Надмірність тестів взаємодій
    100% покриття не завжди потрібне
  • 46. На що дивитись далі
    Unit testing patterns
    Mocks/stubs/fakes, isolation frameworks
    TDD, Test Driven Development
    Contracts, Contract Driven Development
  • 47. Q&A
    Code-driven testing
    Олександр Павлишак, 2011
    pavlyshak@gmail.com

×