Всем привет!
Возник такой вопрос: насколько, разрабатывая программы для тестирования, вы следуете принципам чистого кода, SOLID etc? Или же вы считаете, что для автотестов качественная архитектура не так важна и можно писать код с минимальными усилиями в рамках архитектурных решений?
Буду благодарен за обоснованные позиции.
ОО, Мне кажется это вечный спор. :)) Вот, например, у нас работе так. 
Для автотестов качественная архитектура важна, потому что после вас могут придти другие люди, которым это все разгребать и поддерживать
Или даже самому разбираться в своем же коде через месяц будет гораздо проще и быстрее, если архитектурно проект построен грамотно.
Интересно и как вы живете на одном проекте с разным видинием подхода к архитетуре? У меня, например, на проекте ситуация такая, что в никакую не хотят писать код хоть с каким-то прицелом на долгую поддержку и расширяемость. Руководство хочет результат прямо сейчас, и тех лид как бы думает точно также: “Сейчас запилим, а там разберемся”. Я пытаюсь объяснить, что “а там разберемся” это будет переписывание все заново, но не помогает.
Бегите оттуда, вас не любят 
А если серьезно, конечно, так бывает и часто. Постарайтесь максимально прикрыться, чтобы в случае большого взрыва не просто сказать “Ну вот, я же говорил!”, а чтобы было что-то материальное, на что можно сослаться - переписка, нотариально заверенные скриншоты и т.п. Чтобы им, а не вам, стало мучительно больно за свое поведение.
Можно создать простенькие требования к написанию кода. Все с радостью под ними подпишутся. Соблюдать, конечно, не будут. Зато у вас будет железобетонный аргумент в случае чего.
Ну, пытаемся к компромиссу прийти. Тех лиды считают, что не надо писать Framework, а пилить, что попроще. А мы же пытаемся сделать по-красивее. Вот так и живём
Спасибо всем за ответы ). Конечно мое видение такое:
по личному опыту скажу что иногда лучше сделать просто и быстро чем пилить фреймворк который все кейсы будет учитывать, но потом что то пойдет не так (проект поменяет свое русло или еще что то ) и все ваше затраченое время пойдет коту под хвост.
P.S. я о гавнокоде не говорю, а о том что все-все все учитывать это плохой вариант.
Мы с тобой работаем?)) Никто не говорит, что нужно учитывать все все все. Есть практики и методы позволяющие писать поддерживаемый и расширяемый код. Расширяемый != поддерживающий все все. Как раз таки если все пойдет в другое русло, то вы весь ваш простой и быстрый код выкинете
не вместе просто был опыт когда напилился фреймворк - основная часть которого так и не заиспользовалась
для каждого проекта есть такая вероятность, но это ведь не значит, что нужно делать абы как на случай - а вдруг все надо будет переделывать. В таких случаях изменения кода продукта не менее значительные, чем ваши, и у вас будет время что подправить русло. В любом случае все всегда остается за вами ). Я лишь поинтересовался какие подходы кто использует
было усложнение логики и добавленые уровни абстракции - через которые было сложнее писать код. Но потом оказалось что оно не принесло велью. 
Автоматизация - это долгосрочная инвестиция. От прочности заложенного фундамента зависит ее эффективность в будущем.
Если следовать принципу:
вероятней всего первое время это даже будет отлично работать.
Но, как правило, если рассмотреть более длительный промежуток времени, можно будет заметить постепенную деградацию, выражающуюся в первую очередь в увеличении времени на поддержку автотестов / фреймворка / инфраструктуры и т.п.
А когда дело доходит до точки невозврата - QA инженеры тратят все свое время на поддержку - эффективность автоматизации сводится к нулю. К вам тут же прибегают лиды, менеджеры и прочие “Сейчас запилим, а там разберемся”, и начинают искать крайнего, с умным видом разбираться в причинах, принимать ошибочные решения о том, что необходимо нанимать больше людей и т.п.
П.С. У нас для автоматизаторов действуют те же правила, что и для девелоперов. Начинающих сразу приучают использовать quality плагины, думать в лучших традициях ООП, не забывать о патернах, строго следить за тем, что пушится в репозиторий и т.п.
Так речь о написании качественного кода. Много не значит хорошо. А по поводу неиспользуемого кода, то есть хороший принцип You aren't gonna need it - Wikipedia
Ммм сейчас стараюсь заложить масимум абстракции…
несколько раз приходилось переписывать из-за этого много кода
или костыли писать
приятно знать, что большинство за написание качественного кода, а не на скорую руку)
А что конкретно за плагины?..
Конкретно для Java: Checkstyle, PMD, FindBugs. В зависимости от используемого build tool, они могут либо по отдельности подключаться, либо в виде плагинов-агрегаторов. Некоторые предпочитают ставить SonarQube сервер и т.п. Вариантов на самом деле много.
testomat.io управление авто тестами