Unit тестирование на энтузиазме

Unit-тестирование на энтузиазме

Кожевников ДмитрийАКБ Росбанк

[email protected]

8-я конференция .NET разработчиков6 апреля 2014dotnetconf.ru

http://www.dotnetconf.ru/

2Unit-тестирование на энтузиазме, Кожевников Дмитрий

Докладывает

• Кожевников Дмитрий Олегович • .Net разработчик• Инженер-программист, АКБ Росбанк• Интересы: паттерны и практики

разработки качественного кода, unit-тестирование и TDD, новые технологии в стеке .net, больше кода для бога кода

• Email [email protected]

mailto:[email protected]


О чём я НЕ буду говорить

• Что такое unit-тесты и зачем?

• Как сделать код слабосвязным?

• Что за принципы SOLID?

• Как это - Inversion of Control?

• Программирование на основе интерфейсов?


Перегруженные

unit-тесты

Большая инерция

кода

Тестируемость

вместо простоты


Нарушение SRP

Много зависимостей в классах

Тяжелые алгорит

мы

Инициализация в конструк

торе


… и, как следствие

Код

слабосвязный,

а тесты

монструозны


Наши решения

ПРИНЦИПЫ

как Боб Мартин

ЗАПАХИ чем

пахнет наш код


ПАТТЕРНЫ

прикладное

велосипедостроение

МЕТРИКИкак будто и так

не видно


Принципы



Паттерны

Список команд

Шаг за шагом

Нормальная

декомпо-зиция

Отделение инициа-лизации

Контекст для

вызовов



Нормальная декомпозиция

NormalDecompositionPerformLogic();

IDependency1

MidResult1 SubAction();

IDependency2MidResult2 SubAction(MidResult1 r);

IDependency3MidResult3 SubAction(MidResult2 r);



Нормальная декомпозиция

+ -



StepsDirector

PerformLogic();

StepByStep

MidResult1 Step1();MidResult2 Step2(MidResult1 r);MidResult3 Step3(MidResult2 r);

StepByStep_Tests

Step1_Test();Step2_Test();Step3_Test();





+ -Сложно выделить шаги

Страдает инкапсуляция

Промежуточные данные

Сохранение логики внутри класса

Мало новых зависимостей

Можно выделить много шагов



PerformLogic();

CommandsDirector ICommand

Execute(MidData data);int SortOrder { get; }

Command1


Command2





+ -


Много шагов

Нужна гибкость

Шаги независимы

Логика в одном классе Нормальная

декомпозицияШаг за шагомСписок команд

Выделить более крупные

шаги-+

-+

+-

+-


Отделение инициализации

InitializedObject

MidResult3 { get; set; }Ctor(MidResult3 r, IDependency3 service);Initialize();Action();

InitializedObject_TestsCtor_Test();Initialize_Test();Action_Test();




Отделение инициализации

+ -Ограничение инкапсуляции

состояния класса

Дополнительный вызов метода

инициализации

Разгрузка тестов от поддержки логики

конструктора

Разгрузка конструктора от части

зависимостей


Контекст вызовов

Actor

Action1(IDependency1 d);Action2(IDependency2 d);Action3(IDependency3 d);

IDependency2

IDependency1

IDependency3

Facade

Action1();Action2();Action3();

WorkContext

Act<T>(Action<T> act);TR Get<T,TR>(Func<T,TR>

f);

ILocator

T Resolve<T>();




+ -Таки вариант ServiceLocator

Чудной интерфейс

Разгрузка конструктора от

контекстных зависимостей

Контекст для логики (DCI?)

Контекст вызовов


Много заглушек и глубокая

настройка в Arrange

Дублирование кода в

Arrange

Вспомогательные

методы в фикстурах

Защищённые

конструкторы только для тестов

Тестовые реализации вместо

моков

Зависимости только

для конструкто

ра


Метрики по переменным:

Тестируемые объекты

Моки - классами в тестовой сборке

Моки\Стабы созданные

фреймворком изоляции

Переменные библиотечных типов

слож

ность


Настройки выброса

исключенийНастройки сallback’ов

Настройки методов

Настройки свойств

Метрики по настройкам стабов/моков:

слож

ность


ИтогиРазделение

ответственности - необходимость, а

не искусств

о

Код определ

яет качество

тестовСлабосвязный

дизайн !=

тестируемый

дизайн

Тестируемый

дизайн !=

простой дизайн


ВопросыКаков порог

входа в практики

unit-тестиров

ания?

Как достигнуть баланса

между тестируемостью и простото

й?Оправдывают ли

unit-тесты

усложнение

дизайна?

Нужны ли

паттерны тестируе

мого кода?


Ссылки

• Антипаттерны TDD http://habrahabr.ru/post/43761/• Те же посылки, но совсем другие решения, цикл

статей, Юрий Солдатенков http://solyutor.blogspot.ru/2012/03/ock.html

• Тестируемый дизайн vs хороший дизайн, Сергей Тепляков http://sergeyteplyakov.blogspot.ru/2013/04/vs.html

• Проект MockMetrics, R# плагин подсчёта метрик unit тестов https://github.com/KozhevnikovDmitry/MockMetrics/tree/trunk

http://habrahabr.ru/post/43761/

http://solyutor.blogspot.ru/2012/03/ock.html

http://sergeyteplyakov.blogspot.ru/2013/04/vs.html

https://github.com/KozhevnikovDmitry/MockMetrics/tree/trunk

https://github.com/KozhevnikovDmitry/MockMetrics/tree/trunk


Спасибо за внимание

Кожевников ДмитрийАКБ Росбанк

[email protected]

mailto:[email protected]

Software

Unit тестирование на энтузиазме