Я бы предпочел не заострять внимание на технической стороне, ибо реализовать можно что угодно и как угодно (да еще и спрятать это таинство от разработчика, как ASP.NET Web Forms, а жесткие определения здесь невозможны без кучи уточнений.
Когда специалисты говорят о фронтенде, они имеют в виду чать логики, которая непосредственно относится к интерфейсу, то есть серверные шаблоны пишут фронтенд-разработчики, бэкенд лишь просовывает туда данные.
Просто надо понимать, что продукты делаются максимально доступным для всех, а делать больше, тяжелее и тд не лучший вариант
…
если у него i7. — то и продукт должен быть под стать
Речь шла про опциональный вариант, нужно понимать, что от этого доступность не страдает.
TDD не предполагает изменения. Более того, даже итеративные методики разработки, вроде Scrum, не позволяют менять ТЗ посреди спринта. А после каждого спринта должно быть «готовое к употреблению» ПО (или его функционирующая часть).
Знание тестов до реализации провоцирует удовлетворять требованиям тестов, а не ТЗ
Тесты пишутся по ТЗ, здесь не должно быть противоречий.
Структуру модулей должен задавать архитектор системы.
Согласен.
«Большое» количество не означает качества тестирования. Можно написать 100 тестов на положительных числах и забыть про отрицательные
Голову отключать — вообще порочная практика.
Думаю, что и вам понятно, что тестирование и отладка в отладчике происходит раз в 5-10 быстрее, чем тестирование и отладка в пакетном режиме, то есть вставкой операторов печати и задания условий.
Мне понятно, что тест найдет очевидную для него ошибку на порядки быстрее, чем отладчик подключится к процессу. Не говоря уже о процессе занимательного поиска места происшествия. Тесты же все равно придется писать, хоть перед кодом, хоть после… И, да, опережая ваши аргументы, логгирование и грамотную систему детектирования ошибок это не отменяет =)
почему у вас программисты такого уровня, что вам приходится вводить меры для принудительной модульности?
Бывают новички, бывает легаси. А юнит-тесты стимулируют рефакторинг, это тоже хорошо.
Хорошие программисты — это коты, они работают там, где им нравится.
Хорошие программисты дают хороший и поддерживаемый результат. Гениев-джедаев любят стартапы, а ненавистный вами интерпрайз или просто крупные продуктовые компании скорее сделают выбор в пользу нескольких «рабочих лошадок». Пусть это дороже, но bus factor никто не отменял.
Документирование кода тестами вместо самодокументирующего кода...
Возможно. Но что мешает писать тесты в поддержку самодокументирующемуся коду?
ЗЫ Цитата, кстати, интересная, но холиварить о ней я конечно же не буду =)
Жалко, что вы не читали формализованные стандарты языков.
Не экспериментируйте с этим, говорят, затягивает.
Не думаю, что вам удастся найти такого архитектора, который сможет назвать хотя бы 80% разночтений.
Без комментариев.
Если программист имеет возможность прочитать тесты до реализации — это плохо
TDD-тесты должны отражать AC. Программист же может читать ТЗ до реализации, верно? =)
Какая тогда польза от TDD?
Очевидно, что это принудительная модуляризация, покрытие юнит-тестами стремится к 100%, что само по себе обеспечивает некоторый уровень качества (еще до QA и DevQA) и документирует код.
Чем оправдываются его накладные расходы?
Сокращением времени на дебаг и большим количеством тестов «из коробки».
Он формализован настолько, что есть официальный документ. Архитектор нашего проекта конкретной реализации подготовит свой документ, где все разночтения будут разрешены.
Разработка снизу вверх такого сложного ПО — это верх идиотизма. Если этим болеет менеджмент, то какой спрос с инструмента разработки?
TDD не запрещает разрабатывать сверху вниз.
Парное программирование реализуемо и для TDD. Без разницы кто пишет тесты, лишь бы они были раньше, чем имплементация.
TDD не отменяет QA. Равно как и юнит-тесты не отменяют его.
В каждой шутке есть доля шутки. В принципе, если под «Сервер» понимать единое приложение, то SPA так и работает. Но деплой, да и вообще поддержка одного приложения — это недостаточно весело, правда?)
Задача тестов в TDD — чтобы желаемое сошлось с действительным. Если у вас кривое «желаемое», то это не в инструменте дело, а в руках, которые его держат.
Я далек от хипстерского современного фронта, но он же не имеет доступа к файловой системе клиента и не умеет (повсеместно) в клиентские БД? То есть будут запросы к бэкенду на любой чих. Проксирование данных на «фронтовов бэкенде» — это сложное решение, как мне кажется, без особой пользы увеличивается количество подсистем, требующих поддержки.
Стремление хорошее, но учитывая, насколько плотно сейчас взаимодействует фронтенд с бэкендом, то фронт должен хорошо пожирнеть в ближайшее время, хотя бы до уровня нативных мобильных приложений, чтобы такая идея окупилась. ИМХО, конечно.
Там такую необходимость даже специально проигнорировать не получится — компилятор/линковщик напомнит.
Когда специалисты говорят о фронтенде, они имеют в виду чать логики, которая непосредственно относится к интерфейсу, то есть серверные шаблоны пишут фронтенд-разработчики, бэкенд лишь просовывает туда данные.
Технически реализуемо, но не встречал таких.
Речь шла про опциональный вариант, нужно понимать, что от этого доступность не страдает.
TDD не предполагает изменения. Более того, даже итеративные методики разработки, вроде Scrum, не позволяют менять ТЗ посреди спринта. А после каждого спринта должно быть «готовое к употреблению» ПО (или его функционирующая часть).
Тесты пишутся по ТЗ, здесь не должно быть противоречий.
Согласен.
Голову отключать — вообще порочная практика.
Мне понятно, что тест найдет очевидную для него ошибку на порядки быстрее, чем отладчик подключится к процессу. Не говоря уже о процессе занимательного поиска места происшествия. Тесты же все равно придется писать, хоть перед кодом, хоть после… И, да, опережая ваши аргументы, логгирование и грамотную систему детектирования ошибок это не отменяет =)
Бывают новички, бывает легаси. А юнит-тесты стимулируют рефакторинг, это тоже хорошо.
Хорошие программисты дают хороший и поддерживаемый результат. Гениев-джедаев любят стартапы, а ненавистный вами интерпрайз или просто крупные продуктовые компании скорее сделают выбор в пользу нескольких «рабочих лошадок». Пусть это дороже, но bus factor никто не отменял.
Возможно. Но что мешает писать тесты в поддержку самодокументирующемуся коду?
ЗЫ Цитата, кстати, интересная, но холиварить о ней я конечно же не буду =)
Не экспериментируйте с этим, говорят, затягивает.
Без комментариев.
TDD-тесты должны отражать AC. Программист же может читать ТЗ до реализации, верно? =)
Очевидно, что это принудительная модуляризация, покрытие юнит-тестами стремится к 100%, что само по себе обеспечивает некоторый уровень качества (еще до QA и DevQA) и документирует код.
Сокращением времени на дебаг и большим количеством тестов «из коробки».
Он формализован настолько, что есть официальный документ. Архитектор нашего проекта конкретной реализации подготовит свой документ, где все разночтения будут разрешены.
Разработка снизу вверх такого сложного ПО — это верх идиотизма. Если этим болеет менеджмент, то какой спрос с инструмента разработки?
TDD не запрещает разрабатывать сверху вниз.
Парное программирование реализуемо и для TDD. Без разницы кто пишет тесты, лишь бы они были раньше, чем имплементация.
TDD не отменяет QA. Равно как и юнит-тесты не отменяют его.
Это ошибка проектирования, архитектуры. TDD от этого не лечит и не должен.
Могу понять ваше негодование, что этот подход не всесилен, но почему же он вреден?
Еще хуже. Искать по такому списку — незавидное удовольствие, закладку не сделаешь.
То, что для для такой банальной операции в вебе стал нужен i7 — это еще одна притензия.
У меня есть возможности, я хочу их реализовывать. Разве это плохо?
Интеграционные — не пройдут.
Задача тестов в TDD — чтобы желаемое сошлось с действительным. Если у вас кривое «желаемое», то это не в инструменте дело, а в руках, которые его держат.
Какое-то у вас странное TDD.
Это я опережаю возможный аргумент, что кэшировать необходимые данные можно было бы на «фронтенд-бэкенде».
хипстерскогосовременного фронта, но он же не имеет доступа к файловой системе клиента и не умеет (повсеместно) в клиентские БД? То есть будут запросы к бэкенду на любой чих. Проксирование данных на «фронтовов бэкенде» — это сложное решение, как мне кажется, без особой пользы увеличивается количество подсистем, требующих поддержки.