Комментарии 21
появляются когда мы захотим иметь несколько параметризованных тестов в одном тест классе
Для junit5 вообще не проблема.
нам пришлось форкать electricspock и добавлять свои фиксы.
И где PR-ы в основной репозиторий?
Интересный опыт ! Groovy.. он такой
Ну и потом, вы же активно пользовались плюсами, если бы скажем у вас не было параметризованных тестов — вам бы пришлось написать на порядки больше тестов, и потратить время на их разработку. То есть, в чем-то вы может и проиграли, а в чем-то выиграли (например время), точно это сказать сложно. И то, что вы сейчас нашли фреймворк получше — вполне логично, в конце концов, я лично спок применял еще в лохматом 2010 году. То есть он далеко не новый, ему лет 14. С тех пор вполне могло и должно было появиться что-то получше.
Проблема была зарыта глубоко и нам пришлось форкать electricspock и добавлять свои фиксы. Во-первых, это создает громадный bus factor
Вы уверены что вы понимаете что такое bus factor?
Вполне. Возможно мы вкладываем разные понятия в этот термин)
Бас фактор, приводит к тому, что когда увольняется человек, разобравшийся в electricspock достаточно глубоко, мы получаем проблему когда никто не знает, как исправить ошибку в библиотеке, если она возникнет.
В любом случае это можно назвать даже train factor или как угодно, суть проблемы я описал в полной мере)
Если честно, не понял в чём было преимущество написания тестов на groovy? Пытались решить какую-то проблему таким подходом?
скорее преимущество Spoc, автор не указал другие фичи, например когда у вас в ассерте выражение и оно не матчится, то в консоле будет расписано по шагам как оно вычисляется (результаты вызова цепочки foo.bar().substring(5) - вам напишут что было в foo что в bar и что после substring(5) ) а не просто тру!=фалсе - ошибка братан!
ну и в целом тесты сильно короче и наглядней получаются в томчисле благодаря groovy - хочешь лист - просто пиши "[1,2]" и т.д. и т.п.
другое дело, что это не java и надо порой шевелить мозгами и разбираться как с сами фреймворком так и груви, а всем лень.
В нашем случае одним из поинтов было то, что на споке получаются, читаемые и поддерживаемые параметризованные тесты, даже если они большие и их много на один тестовый класс)
Плюс с точки зрения читаемости спок довольно хорош, когда надо понять верхнеуровнево, что проверяется в тесте)
Плюс бекендеры в то время писали тесты на груви и мы решили перенять у них такую экспертизу (можно много обсуждать насколько это было удачное решение)
given:
when:
then:
Крутая статья!
Если у вас только параметризованных тестов 3к, значит обычных еще больше, не думали ли написать автоматический конвертер спок2котест, базирующийся на PSI?)
Как мы играли в тесты на Groovy и проиграли