Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SOLIDарность: Тестирование как разработка

1,294 views

Published on

Презентация Игоря Горчакова на SQA Days-16
14-15 ноября 2014, Санкт-Петербург, Россия
www.sqadays.com

Published in: Education
  • Be the first to comment

SOLIDарность: Тестирование как разработка

  1. 1. SOLIDарность Тестирование, как разработка
  2. 2. Об авторе Игорь Горчаков skype : igor-gorchakov e-mail : gorchakov.igiv@gmail.com
  3. 3. Качество кода в тестировании • Многие не считают, что разработка автотестов – это разработка. • Иногда и разработчик автотестов не считает, что он занимается разработкой
  4. 4. Что такое хороший код? • Что такое код? • Что такое хороший код? • Почему важен хороший код?
  5. 5. Дизайн Дизайн – это результат процесса проектирования : декомпозиция системы, определение поведения и характеристики отдельных компонент и их взаимодействия.
  6. 6. Отсутствие гибкости (Rigidity) Код тяжело поддается изменениям. Изменения в одном месте, вызывают изменения в других частях системы приводя к эффекту «снежного кома».
  7. 7. Хрупкость (Fragility) Код легко «ломается». Т.е. после осуществления изменения код может сломаться еще в нескольких других местах.
  8. 8. Монолитность (Immobility) Компоненты настолько сильно связаны друг с другом, что их сложно разделить друг от друга и переиспользовать.
  9. 9. Вязкость (Viscosity) Сделать что-то хорошо, очень сложно. Существующий код сам провоцирует на дальнейшее увеличение количества «хаков» и «костылей».
  10. 10. Излишняя сложность (Needless complexity) Код содержит в себе архитектурные решения, необходимость в которых еще не назрела.
  11. 11. Излишняя повторяемость (Needless repetition) код содержит в себе дублирование, особенно такое, которое легко устраняется
  12. 12. Нечитабельность (Opacity) код сложен для чтения и понимания.
  13. 13. Признаки хорошего дизайна • Гибкость • Прочность • Переиспользуемость • Отсутствие вязкости • Простота • Отсутствие дублирования кода • Читабельность
  14. 14. Что такое SOLID? • S - Single responsibility principle • O - Open/closed principle • L - Liskov substitution principle • I - Interface segregation principle • D - Dependency inversion principle
  15. 15. Single responsibility principle Не должно быть больше одной причины для изменения класса
  16. 16. Примеры
  17. 17. Примеры
  18. 18. Решение
  19. 19. Open/closed principle программные сущности (классы, модули, методы и т.д.) должны быть открыты для расширения, но закрыты для изменения
  20. 20. Пример
  21. 21. Пример
  22. 22. Решение
  23. 23. Liskov substitution principle Объекты в программе могут быть заменены их наследниками без изменения свойств программы
  24. 24. Пример
  25. 25. Пример
  26. 26. Решение
  27. 27. Решение
  28. 28. Interface segregation principle Много специализирован ных интерфейсов лучше, чем один универсальный.
  29. 29. Пример
  30. 30. Пример
  31. 31. Решение
  32. 32. Решение
  33. 33. Dependency inversion principle Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
  34. 34. Пример
  35. 35. Пример
  36. 36. Тестируемость?
  37. 37. Решение
  38. 38. Решение
  39. 39. Тестируемость
  40. 40. Не забываем! • DRY – Don’t repeat yourself (не повторяй себя) • KISS – keep it simple stupid (делайте вещи проще) • YAGNI - You ain’t gonna need it – вам это не понадобится
  41. 41. Заключение Принципы, а не строгие правила Нет универсальных рецептов
  42. 42. Вопросы? Об авторе : Игорь Горчаков skype : igor-gorchakov e-mail : gorchakov.igiv@gmail.com Литература : Принципы, паттерны и методики гибкой разработки на языке C# (Agile Principles, Patterns and Practices in C#)

×