SOLIDарностьТестирование, как

разработка

Об авторе

Игорь Горчаков

skype : igor-gorchakov

e-mail : gorchakov.igiv@gmail.com

Качество кода в тестировании

• Многие не считают, что разработка автотестов – это разработка.

• Иногда и разработчик автотестов не считает, что он занимается разработкой

Что такое хороший код?

• Что такое код?

• Что такое хороший код?

• Почему важен хороший код?

Дизайн

Дизайн – это результат процесса проектирования : декомпозиция системы, определение поведения и характеристики отдельных компонент и их взаимодействия.

Отсутствие гибкости (Rigidity)

Код тяжело поддается изменениям. Изменения в одном месте, вызывают изменения в других частях системы приводя к эффекту «снежного кома».

Хрупкость (Fragility)

Код легко «ломается». Т.е. после осуществления изменения код может сломаться еще в нескольких других местах.

Монолитность (Immobility)

Компоненты настолько сильно связаны друг с другом, что их сложно разделить друг от друга и переиспользовать.

Вязкость (Viscosity)

Сделать что-то хорошо, очень сложно. Существующий код сам провоцирует на дальнейшее увеличение количества «хаков» и «костылей».

Излишняя сложность (Needless complexity)

Код содержит в себе архитектурные решения, необходимость в которых еще не назрела.

Излишняя повторяемость (Needless repetition)

код содержит в себе дублирование, особенно такое, которое легко устраняется

Нечитабельность (Opacity)

код сложен для чтения и понимания.

Признаки хорошего дизайна

• Гибкость

• Прочность

• Переиспользуемость

• Отсутствие вязкости

• Простота

• Отсутствие дублирования кода

• Читабельность

Что такое SOLID?• S - Single responsibility principle

• O - Open/closed principle

• L - Liskov substitution principle

• I - Interface segregation principle

• D - Dependency inversion principle

Single responsibility principle

Не должно быть больше одной причины для изменения класса

Примеры

Примеры

Решение

Open/closed principle

программные сущности (классы, модули, методы и т.д.) должны быть открыты для расширения, но закрыты для изменения

Пример

Пример

Решение

Liskov substitution principle

Объекты в программе могут быть заменены их наследниками без изменения свойств программы

Пример

Пример

Решение

Решение

Interface segregation principle

Много специализированных интерфейсов лучше, чем один универсальный.

Пример

Пример

Решение

Решение

Dependency inversion principle

Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции.

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Пример

Пример

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

Решение

Решение

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

Не забываем!

• DRY – Don’t repeat yourself (не повторяй себя)

• KISS – keep it simple stupid (делайте вещи проще)

• YAGNI - You ain’t gonna need it – вам это не понадобится

Заключение

Принципы, а не строгие правила

Нет универсальных рецептов

Вопросы?

Об авторе : Игорь Горчаковskype : igor-gorchakove-mail : gorchakov.igiv@gmail.com

Литература : Принципы, паттерны и методики гибкой разработки на языке C#(Agile Principles, Patterns and Practices in C#)