t.me/atinfo_chat Telegram группа по автоматизации тестирования

Создание фреймворка для регрессионного тестирования

Ну я лично предпочитаю не зацикливаться на стареньком, а пробовать всегда что-то новое. Пусть это и занимает много свободного времени, но с другой стороны, чем больше инструментов знаешь (полезных!), тем гибче ты становишься, и тем ниже будет порог вхождения в новый проект любой сложности.

Причем, знать досконально тот или иной инструмент вовсе не нужно. Те теоретики, которые углубляются в детали до мозга костей, как правило никогда не укладываются в эстимейты. Да и смысл в углублении? Важно знать, как / чем та или иная задача может быть решена, а найти нужное API в javadocs - даже студент сможет. И если для решения задачи мне нужен только 1 метод, зачем мне изучать структуру доброй сотни? Код везде одинаков, и если умеешь его читать, то смысла нет хранить в голове коллекцию API всех возможных библиотек. Достаточно знать об их существовании и возможностях продукта.

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

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

По факту, на хорошую обертку над JDBC тоже уйдет немало времени у новичка, т.е. не ясно, что еще будет быстрей - разобраться в готовом или написать свое. Я в такой ситуации сразу вспоминаю универ, когда мы ручками создавали строковые функции, реализовывали сортировки и т.п. А спустя некоторое время появились фреймворки, все это реализующие. Но никто ведь сейчас не игнорит методы класса String или Arrays.Sort, изобретая свои, ведь так?
В любом случае пусть автор пробует. Наше дело - подсказать, его - выбрать и заимплементить.

По поводу архитектуры согласен. По поводу технологий: с плохо продуманной архитектурой что-либо воткнуть во фреймворк без последствий будет весьма проблематично. Да и эти два этапа очень тесно связаны между собой. Но это все - лирика. Я думаю, что автор получил интересующие его ответы, так что можно заканчивать с этой темой.

Спасибо всем за советы! Пока не определился что делать: брать “готовый велосипед” или писать JDBC для моих запросов. И то, и другое для меня новое (особенно готовый фреймворк). Но здесь ,как многие сказали, нужно очень осторожно и с умом подойти к архитектуре.
В любом случае планирую делать “по кускам” (по пунктам), а потом проверять что вышло. И, если будет затык, попрошу ваших советов.