2. Agenda
• зачем нужны юниттесты?
• unit of coverage/work
• требования к юниттестам и как
не нужно писать тесты
• повторное использование
кода(initialization, asserts)
3. Зачем нужны юниттесты?
поиск багов? (интеграционные тесты)
регрессионное тестирование?
(интеграционные тесты)
улучшение качества кода(дизайна
компонентов)
поиск багов в случае рефакторинга!
(изменение поведения компонента)
источник спецификации системы
17. Поддерживаемые (Maintainable)
• Тестируйте только public интерфейс
• Не используйте объекты, которые
•
•
•
непостоянны(DateTime.Now, Thread,
Random etc)
Не дублируйте продакшин логику
Не тестируйте всё в одном тесте
Многократно используйте код для
тестов(initialize, assert etc)
26. Test data initialization:
Object Mother pattern
Test Data builder pattern
•
•
SUT initialization:
SUT Mother pattern
SUT Builder pattern
Auto-Mocking container
•
•
•
27. Object Mother Pattern
var basket = CreateWithDiscount();
var basket = CreateWithSmallDiscount();
var basket = CreateWithLargeDiscount();
var basket =
CreateWithLargeDiscountButWithSpecialOffer();
…
28. Fluent Builder Pattern
var basket = new BasketBuilder().Build();
var basket = new
BasketBuilder().WithSmallDiscount().Build();
var basket = new BasketBuilder()
.WithLargeDiscount()
.WithSpecialOffer()
.Build();
…
- Make each test orthogonal (i.e., independent) to all the others
- Don’t make unnecessary assertions
- Mock out all external services and state
- Avoid unnecessary preconditions
- Don’t unit-test configuration settings
- Name your unit tests clearly and consistently
Trust worthy
- Make it easy to run
- Avoid test logic
- Don't repeat production logic
- Dont't use things that keeps changing
Maintanable
- Test only publics! Avoid testing private/protected memebers
(makes your tests more brittle)
- Re-use test code:
- Create objects using common methods
- Enforce test isolation
- No dependency between tests
- Don't run a test from another test
-
- Test one thing
- Avoid multiple asserts on diffrerent objects
- Create multiple tests
- Hard to name
-
- one mock per test
Readable tests:
- project structure
- No magic values
- Naming a unit tests
- Naming variables
- separate assert from action - test structure
- Use test cases
Describes a collection of methods that can create test data objects according to different scenarios