И вот как теперь жить? Мой тезка (по имени и фамилии) топит за Геркин... А я - активно топлю против...
Несколько сумбурно поясню свою позицию: Мы пытаемся хороший код на хорошем языке программирования заменить очень урезанным языком описания тест кейсов (Gerkin). Основная фишка данного подхода - «любая домохозяйка может написать тест». Проблема в том, что «домохозяйки» тесты не пишут - обычно пишут тесты все-равно разработчики или тестировщики. А им удобнее пользоваться полнофункциональным языком программирования.
Хороший фреймворк для тестов требует довольно аккуратной поддержки со стороны разработчиков. Я видел ситуации когда BDD тесты превращались в огромную плохо поддерживаемую портянку. По которой невозможно навигироваться с помощью IDE, рефакторить их тоже нет никакой возможности.
Часто разработчики, которые делают фичу делают что-то маленькое для поддержки в тестах и те кто вынужден писать автоматизированные тесткейсы - пишут их и мучаются, т.к. они не в состоянии поменять инфраструктуру (ну или цикл изменения этой инфраструктуры довольно длинный - проще написать как есть).
Мой путь - писать тесты разработчиками. Они пишут тесты на их языке программирования. Причем все возможности современных IDE им помогают. Если что-то больно (неудобно) писать - сам разработчик мучается и это именно тот человек который может что-то с этим сделать.
Да, на разработку фич требуется больше времени разработчиков. Но, как мне кажется, на длительном промежутке времени оно может окупаться.
Касательно Gerkin тестов - они наверное могут быть, но не надо их ставить во главу угла. Это инструмент, у которого есть плюсы и минусы. Нужно аккуратно думать прежде чем внедрять его.
Добавлю свою копеечку:
При использовании ORM библиотек необходимо проводить тестирование производительности на ранних этапах разработки.
Практически все ORM библиотеки грешат тем, что теряется контроль того, какие запросы они выполняют, а это может привести тормозам.
На небольших проектах это не критично, но вот если проект большой, я предпочту, чтобы Data Access Layer был максимально прозрачным (это упростит последующую поддержку и ловлю багов).
В последних нескольких проектах использую BlToolkit — очень нравится, но это не ORM.
По моему мнению, соглашение о наименовании, грамотно составленное - является базой, от которой можно двигаться в сторону качественного кода. Фраза: "ТО Сей4ас Я наPушИЛ соГлашеНИЕ По НАИМеноВанИЮ" - ясна, но чтобы понять ее, мне пришлось еще раз перечитать предложение.... И это - "русский" текст, а что делать, если подобным образом оформлен код, несущий в себе сложную логику?....
Из моей практики: качественного кода можно добиться только за счет постоянного использования такой практики как Code Review и всяческих утилит по анализу кода.
И вот как теперь жить? Мой тезка (по имени и фамилии) топит за Геркин... А я - активно топлю против...
Несколько сумбурно поясню свою позицию:
Мы пытаемся хороший код на хорошем языке программирования заменить очень урезанным языком описания тест кейсов (Gerkin).
Основная фишка данного подхода - «любая домохозяйка может написать тест». Проблема в том, что «домохозяйки» тесты не пишут - обычно пишут тесты все-равно разработчики или тестировщики.
А им удобнее пользоваться полнофункциональным языком программирования.
Хороший фреймворк для тестов требует довольно аккуратной поддержки со стороны разработчиков.
Я видел ситуации когда BDD тесты превращались в огромную плохо поддерживаемую портянку. По которой невозможно навигироваться с помощью IDE, рефакторить их тоже нет никакой возможности.
Часто разработчики, которые делают фичу делают что-то маленькое для поддержки в тестах и те кто вынужден писать автоматизированные тесткейсы - пишут их и мучаются, т.к. они не в состоянии поменять инфраструктуру (ну или цикл изменения этой инфраструктуры довольно длинный - проще написать как есть).
Мой путь - писать тесты разработчиками. Они пишут тесты на их языке программирования. Причем все возможности современных IDE им помогают. Если что-то больно (неудобно) писать - сам разработчик мучается и это именно тот человек который может что-то с этим сделать.
Да, на разработку фич требуется больше времени разработчиков. Но, как мне кажется, на длительном промежутке времени оно может окупаться.
Касательно Gerkin тестов - они наверное могут быть, но не надо их ставить во главу угла. Это инструмент, у которого есть плюсы и минусы. Нужно аккуратно думать прежде чем внедрять его.
Вот тут вот шикарная подборка русскоязычных подкастов про IT:
https://github.com/unchase/awesome-russian-it/blob/master/Podcasts.md
Кстати, есть обсуждение программы конфернеции в виде подкаста.
При использовании ORM библиотек необходимо проводить тестирование производительности на ранних этапах разработки.
Практически все ORM библиотеки грешат тем, что теряется контроль того, какие запросы они выполняют, а это может привести тормозам.
На небольших проектах это не критично, но вот если проект большой, я предпочту, чтобы Data Access Layer был максимально прозрачным (это упростит последующую поддержку и ловлю багов).
В последних нескольких проектах использую BlToolkit — очень нравится, но это не ORM.
Из моей практики: качественного кода можно добиться только за счет постоянного использования такой практики как Code Review и всяческих утилит по анализу кода.