10 заповедей SDET

10 заповедей SDET

Принцип YAGNI («You aren’t gonna need it»; с англ. – «Вам это не понадобится»): не пишите код, который, как вам кажется, может пригодиться в будущем, но сейчас в нём потребности нет. Вскоре он станет неактуальным и его придётся переписать под конкретную задачу.

YAGNI минимизирует объе\ём ненужной работы и тесно связан с принципом KISS («Keep it simple, stupid»; с англ. – «Не усложняй»): избегать добавления функций и повышения сложности кода до тех пор, пока это действительно не понадобится.

Что касается API, сначала проектируйте интерфейс для простых запросов. По мере необходимости добавляйте дополнительные методы для более сложных вариантов использования.

Напишите руководство, которое поможет разработчику быстро приступить к работе. При изменении API позаботьтесь об обратной совместимости.

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

Меньше ненужного кода – меньше проблемМеньше ненужного кода – меньше проблем

Следование стандарту программирования упрощает обнаружение проблем, поддержку программного обеспечения, снижает риски сбоя и уязвимость к атакам.

Не злоупотребляйте комментариями. При активной разработке комментарии становятся неактуальны, поэтому изначально пишите читабельный код по стандарту вашего языка программирования, чтобы обходиться без них. Комментарии должны отвечать на вопрос «Почему», а не «Что».

Сначала пишите правильный, соответствующий стандартам код, потом оптимизируйте скорость выполнения.

DRY («Don’t Repeat Yourself»; с англ. – «Не повторяйся») – принцип разработки программного обеспечения, нацеленный на уменьшение сложности кода и снижения повторения информации. Сторонники принципа DRY стремятся обеспечить существование только одного способа выполнения кода, объединяя экземпляры повторящегося кода в единый блок, что окупается в долгосрочной перспективе, т. к. ускоряет время разработки.

Ешё раз повторим: не повторяйтесь! ��Ешё раз повторим: не повторяйтесь! ��

DRY важнее в тестируемом коде, чем в тестах, потому что последние выполняются и читаются отдельно, а не как часть большой системы.

Используйте встроенные структуры и типы данных, пишите свои только по необходимости. Ведь за готовыми решениями стоят годы отладки и оптимизации.

Юнит-тест проверяет поведение кода, а не его реализацию. Относитесь к своим тестовым объектам как к «чёрным ящикам», тестируемым через публичный API.

Как выглядит тестирование в процессе разработкиКак выглядит тестирование в процессе разработки

Предварительное написание тестов побуждает использовать небольшие единицы кода, что в большинстве случаев приводит к написанию более чистого кода.

Тесты должны быть написаны так, чтобы их можно было использовать, как документацию.

Небольшие юнит-тесты дают в случае неудачи более ценную информацию – они явным образом указывают что именно не так. Как правило, тест, на который уходит больше 0.1 с, юнит-тестом не является.

Проводите рефакторинг, когда это возможно. Каждое преобразование должно улучшать структуру программы, не изменяя её поведения. Потенциальные преимущества рефакторинга заключаются в повышении читаемости кода и понижении его сложности. Это повысит удобство при сопровождении кода и создаст более простую, чистую и выразительную архитектуру.

Как не должен выглядеть рефакторингКак не должен выглядеть рефакторинг

Сделайте преднамеренную ошибку и убедитесь, что тест работает. В противном случае вы не знаете, что действительно тестируете. Нерабочие тесты уменьшают пользу вашего набора тестов, до такой степени, что, в конце концов, все игнорируют их результаты. Исправляйте или удаляйте такие тесты.

Юнит-тестыЮнит-тесты

Итак, мы вспомнили о таких принципах программирования как YAGNI, KISS и DRY. Также узнали, какой юнит-тест считается медленным и как нужно проводить рефакторинг.