Хм, что-то туповат видимо, но не очень понял — как и где этот… не сказать, что язык, скорее систему, можно потрогать руками? На www.wolfram.com/language/ ссылка «Start Write your own code» помечена как «Coming Soon». Или пока только на примере Mathematica?
Ну, насколько незнакомы? :) Можно обеспечить хорошую читаемость, например Cucumber, в который завернуть Capybara.
Cucumber — по сути генератор тестов на основе простого лексического парсера, можно написать очень понятные обработчики прям на естественном языке. На одной конфе товарищи утверждали, что в такой связке им тест на баг добавил заказчик, который просто нашел косяк в работе сайта. :) Нормально знакомый с IT, но все же.
Идея реально может сыграть для функционального тестирования какого-то внешнего API по принципу черного ящика. Если этот API зафиксирован во времени и его поведение не меняется.
Юнит-тесты — в первую очередь инструмент для разработчика, а в TDD — так вообще инструмент не столько для тестирования, сколько для проработки интерфейсов внутренних сущностей. У меня в работе часто бывает, что вроде бы минорное изменение несколько изменяет модель, и небольшие изменения веером расходятся в 3-4 сущности, для которых надо соответствующим образом обновить тесты. Если разработчик не работает с тестами — то у него связаны руки для внутреннего рефакторинга. Если работает и правит соответствующие тесты — то непонятно, зачем тогда аутсорс.
Понятно, что это учиться надо, и просто так разработчик не начнет писать крутые тесты, это ж надо понимать определенные принципы и хорошо владеть инструментом для тестирования. Но разработчик, который этому научился, получает свой левелап. Переход на регулярное написание тестов что-то изменяет в мозгах, начинаешь смотреть на проблемы развития кода несколько по-другому.
Про функциональное тестирование именно GUI на frontend'е не могу сказать чего-то принципиального, я работаю с backend'ом. Но в любом случае тут важным фактором опять же будет изменчивость интерфейса. Сколько будет стоить поменять какую-то структурную единицу приложения, включая переписывание теста? Как часто могут происходить (из вашего опыта) такие изменения? Спустя какое время после того, как разработчик напишет интерфейс, на этот интерфейс будет написан тест? Кстати, как разработчик будет проверять, что все хорошо и он ничего не сломал? 10-20 раз руками после каждого патча кода? Не быстрее ли ему написать тест, и эти 10-20 раз прогонятся в автоматическом режиме?
Вам — не знаю :) Я вот регулярно выкатывают новые версии серверов, и надо тут логи посмотреть, там конфиг поправить, подебажить код прямо в работе и т.д.
Вы можете залогиниться по ssh на удаленный сервер фактически под любой никсовой осью и использовать там ровно те же инструменты, которые используете у себя на десктопе, сохраняя привычное удобство и скорость работы.
По словам «jvm scala AOT» уже могу угадывать автора, пока-что работает безотказно :) Никита, спасибо за рассказ. А где будут материалы выкладывать? Я б послушал.
Менять можно любые коммиты. Каждое изменение — фактически новый коммит, т.к. меняется SHA, ничего страшного.
Отклонять весь пуш — гораздо логичнее, чем выборочно какие-то коммиты применять, какие-то нет.
Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)
На меня в этом плане серьезно повлиял TDD — вот уж где пришлось овладеть принципом «low cohesion, high coupling». Как только встает задача «протестировать одну фичу из всей этой макаронины» — сразу начинаешь все разделять на разные сущности, код логически становится гораздо проще. Меньше shared state, больше явного взаимодействия.
Да ладно, даже если предположить, что у нас идеальный ревьюер, который никогда не делает глупых ошибков (хотя все люди их делают), то может легко остаться какой-нибудь комментарий в заголовке модуля, где упоминается функционал, или в другом методе, который пользуется этим методом — он просто не попадет в контекст ревью в тако случае
… что lists — это на самом не lists, а оставшееся от прошлой команды название и модель эта теперь везде в тестах называется Things
Начнем с того, что переименуем везде lists в things — вот и начали рефакторинг в сторону упрощения кода. И дальше поехали, упрощать, отделять и абстрагировать :)
coffee> if ('required' in rules || str.length > 0) && result == false then true else false
false
O RLY? Но даже если бы был косяк в синтаксисе — вы игнорите главный тезис, что зачем-то навернули сложности.
Сейчас она изрядно помолодела, а у нынешнего поколения книжки не в моде. Чтению они предпочитают видео, яркие простые картинки и алкоголь
Спасибо, да, запишу на свой счет, что я книжки не читаю и предпочитаю яркие простые картинки и алкоголь, раз вы так лихо про всех все знаете :)
Материал невысокого качества. Это не повод оправдываться «утилитарностью и воздержанием от перфексионизма» — не бойтесь, он вам не грозит. Что бы не тратить время — пишите хороший код сразу, что вам мешает :) Не можете — тренируйтесь! Как раз на тему книг — вам бы «Совершенный код» и «Рефакторинг. Улучшение существующего кода» прочитать. Они не привязаны к языкам и как крутятся вокруг тем хорошего/плохого/достаточно хорошего кода.
По поводу дизайна — не самым лучшим решением преставляется описание правил в виде строки.
Если кто-то совершит опечатку, то об этом узнаете только при вызове метода. Плюс работа зависит от порядка.
Если написать правило «required|trim», то оно провалидирует строчку из пустых пробелов — сначала проверит, что длинна строки больше 0, потом отрежет все пробелы и сохранит новое значение. Очевидно, это косяк дизайна. По хорошему сначала должны применяться все морферы (операции, изменяющие строку), только потом делаться валидация, причем очевидно возникают приоритеты в ошибках.
Для правила «valid_email|required» по хорошему надо в любом случае сначала проверять на required, убедившись, что данные вообще есть, и только потом применять к ним любые другие валидаторы — а у вас первым сработает valid_email и юзер получит ошибку про неправильный email(а не про его обязательность).
Эти проблемы не вылечить одной строчкой, и что бы решение было общим — надо усложнить структуру объекта и логику работы.
Скрывать текст можно тегом <spoiler title="...">...</spoiler>:
Я просто к тому, что это решение на скорую руку — вполне подойдет для решения задачи здесь и сейчас, но вы все-таки статью пишете, которую другие люди будут читать. Мне кажется они заслуживают хорошего продуманого кода. По этой же причине я и говорю про нехватку ООП и OOAD. Как видите, не набрали и десятка плюсов — что как ни это является подтверждением моих слов.
Про запутанный кусок — мне кажется тут не логика запутанная, а вы ее путаете. Если я правильно понимаю, то вы имели ввиду следующее:
if result in [true, false]
if ('required' in rules || str.length > 0) && result == false
... # ловим ошибку
else
.... # перепишем результат
без крыльевонлайновый? Не только же в Мск такие темы интересны :)Cucumber — по сути генератор тестов на основе простого лексического парсера, можно написать очень понятные обработчики прям на естественном языке. На одной конфе товарищи утверждали, что в такой связке им тест на баг добавил заказчик, который просто нашел косяк в работе сайта. :) Нормально знакомый с IT, но все же.
Юнит-тесты — в первую очередь инструмент для разработчика, а в TDD — так вообще инструмент не столько для тестирования, сколько для проработки интерфейсов внутренних сущностей. У меня в работе часто бывает, что вроде бы минорное изменение несколько изменяет модель, и небольшие изменения веером расходятся в 3-4 сущности, для которых надо соответствующим образом обновить тесты. Если разработчик не работает с тестами — то у него связаны руки для внутреннего рефакторинга. Если работает и правит соответствующие тесты — то непонятно, зачем тогда аутсорс.
Понятно, что это учиться надо, и просто так разработчик не начнет писать крутые тесты, это ж надо понимать определенные принципы и хорошо владеть инструментом для тестирования. Но разработчик, который этому научился, получает свой левелап. Переход на регулярное написание тестов что-то изменяет в мозгах, начинаешь смотреть на проблемы развития кода несколько по-другому.
Про функциональное тестирование именно GUI на frontend'е не могу сказать чего-то принципиального, я работаю с backend'ом. Но в любом случае тут важным фактором опять же будет изменчивость интерфейса. Сколько будет стоить поменять какую-то структурную единицу приложения, включая переписывание теста? Как часто могут происходить (из вашего опыта) такие изменения? Спустя какое время после того, как разработчик напишет интерфейс, на этот интерфейс будет написан тест? Кстати, как разработчик будет проверять, что все хорошо и он ничего не сломал? 10-20 раз руками после каждого патча кода? Не быстрее ли ему написать тест, и эти 10-20 раз прогонятся в автоматическом режиме?
Этот пост написан сторонником TDD.
деплой происходит одной командой cap production deploy
Хоть оно и на руби, но в целом является аналогом очень продвинутого баш-скрипта, мы используем во всех проектах вне зависимости от языка
Отклонять весь пуш — гораздо логичнее, чем выборочно какие-то коммиты применять, какие-то нет.
Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)
Начнем с того, что переименуем везде lists в things — вот и начали рефакторинг в сторону упрощения кода. И дальше поехали, упрощать, отделять и абстрагировать :)
O RLY? Но даже если бы был косяк в синтаксисе — вы игнорите главный тезис, что зачем-то навернули сложности.
Спасибо, да, запишу на свой счет, что я книжки не читаю и предпочитаю яркие простые картинки и алкоголь, раз вы так лихо про всех все знаете :)
Материал невысокого качества. Это не повод оправдываться «утилитарностью и воздержанием от перфексионизма» — не бойтесь, он вам не грозит. Что бы не тратить время — пишите хороший код сразу, что вам мешает :) Не можете — тренируйтесь! Как раз на тему книг — вам бы «Совершенный код» и «Рефакторинг. Улучшение существующего кода» прочитать. Они не привязаны к языкам и как крутятся вокруг тем хорошего/плохого/достаточно хорошего кода.
Если кто-то совершит опечатку, то об этом узнаете только при вызове метода. Плюс работа зависит от порядка.
Если написать правило «required|trim», то оно провалидирует строчку из пустых пробелов — сначала проверит, что длинна строки больше 0, потом отрежет все пробелы и сохранит новое значение. Очевидно, это косяк дизайна. По хорошему сначала должны применяться все морферы (операции, изменяющие строку), только потом делаться валидация, причем очевидно возникают приоритеты в ошибках.
Для правила «valid_email|required» по хорошему надо в любом случае сначала проверять на required, убедившись, что данные вообще есть, и только потом применять к ним любые другие валидаторы — а у вас первым сработает valid_email и юзер получит ошибку про неправильный email(а не про его обязательность).
Эти проблемы не вылечить одной строчкой, и что бы решение было общим — надо усложнить структуру объекта и логику работы.
Скрывать текст можно тегом <spoiler title="...">...</spoiler>:
Про запутанный кусок — мне кажется тут не логика запутанная, а вы ее путаете. Если я правильно понимаю, то вы имели ввиду следующее: