Или про тайп-классы на имплиситах, которые позволяют писать какие угодно дженерик решения для любых
типов (да, да, даже для сторонних, стандартных, whatever, и всё это без оберток).
И все-таки хочу понять, над чем надо «думать», а над чем нет. Т.е. TDD, как правило, отождествляют в принципе с написанием тестов, но если мы сначала пишем код, а потом покрываем его тестами (как это и делает Тагир), значит, это уже не TDD?
Должен ли я писать тест, на проверку Content-Type, если он всегда text/html? Кто-то скажет — «А ты не можешь знать, что он всегда будет таким?». Если я один занимаюсь проектом, то я точно могу сказать о невозможности внезапного изменения такого поведения. В ином случае, логично бы написать такой тест, хотя бы ради той эмуляции документации, для других разработчиков.
Т.е. есть достаточно тривиальный функционал, над которым и думать/«думать» то и не нужно, но по TDD нужно «думать», иначе это будет не TDD?
Сам подход, вернее в том виде, в котором я его вижу в статьях и в не очень свежих книгах, противопоставляется подходу проектирования архитектуры. Но как раз в случае проектирования сложных процессов обработки данных(которые, чаще всего, генерируются динамически, приходят из сети или селектятся из базы), я тоже не вижу плюсов в написании тестов до кода. И гораздо быстрее набросать прототип(не этот, который из Design Patterns, а обычный прототип), понять, что тут не так, и удалить его. Что мы получили? Мы именно подумали над предполагаемыми подводными камнями, не потратив на это время. И делали это достаточно удобно, с code completion и прочими прелестями, любезно предоставляемыми IDE.
Кто-то скажет — «да это же не про написание кода, а про подход и философию!». Однако, в каждой статье и книге кровью написано — «сперва тест, потом — код», а это уже не подход, а механизм, что ли!
TL;DR
Почему малейшее написание кода до тестов не приемлимо для TDD?
Ничего не могу сказать против TDD, хочу достичь понимания в этом вопросе.
Статья показалась немного сложной для новичков, от этого и вопрос.
Если будет стоять цель «создать сайт», то лучше уж сразу заняться изучением попсовых CMS, тот же WP.
А если цель «научиться создавать сайты», то в статье слишком много моментом, галопом по Европам.
Имхо.
Такое чувство, будто Вы «C» приписываете чтобы камнями не закидали. Интересно, как Вы лично его используете в связке с PHP. А может и не в связке.
Уж между PHP и Java пропасть в плане «почему-то, какой-то, тупыми методами, и т.п.» куда меньше, нежели между С и PHP.
Почти все проблемы, которые Вы описали решает IDE, ведь для этого она и нужна.
Ну и уж лучше возня с анбоксингом, чем с !==.
iphone точно так же себя ведет, горьким опытом проверено
Hidden text
Уровень новости, конечно, соответствующий
Но по комментариям вижу обратное.
Сколько у вас человек в команде?
Должен ли я писать тест, на проверку Content-Type, если он всегда text/html? Кто-то скажет — «А ты не можешь знать, что он всегда будет таким?». Если я один занимаюсь проектом, то я точно могу сказать о невозможности внезапного изменения такого поведения. В ином случае, логично бы написать такой тест, хотя бы ради той эмуляции документации, для других разработчиков.
Т.е. есть достаточно тривиальный функционал, над которым и думать/«думать» то и не нужно, но по TDD нужно «думать», иначе это будет не TDD?
Сам подход, вернее в том виде, в котором я его вижу в статьях и в не очень свежих книгах, противопоставляется подходу проектирования архитектуры. Но как раз в случае проектирования сложных процессов обработки данных(которые, чаще всего, генерируются динамически, приходят из сети или селектятся из базы), я тоже не вижу плюсов в написании тестов до кода. И гораздо быстрее набросать прототип(не этот, который из Design Patterns, а обычный прототип), понять, что тут не так, и удалить его. Что мы получили? Мы именно подумали над предполагаемыми подводными камнями, не потратив на это время. И делали это достаточно удобно, с code completion и прочими прелестями, любезно предоставляемыми IDE.
Кто-то скажет — «да это же не про написание кода, а про подход и философию!». Однако, в каждой статье и книге кровью написано — «сперва тест, потом — код», а это уже не подход, а механизм, что ли!
TL;DR
Почему малейшее написание кода до тестов не приемлимо для TDD?
Ничего не могу сказать против TDD, хочу достичь понимания в этом вопросе.
Если будет стоять цель «создать сайт», то лучше уж сразу заняться изучением попсовых CMS, тот же WP.
А если цель «научиться создавать сайты», то в статье слишком много моментом, галопом по Европам.
Имхо.
Уж между PHP и Java пропасть в плане «почему-то, какой-то, тупыми методами, и т.п.» куда меньше, нежели между С и PHP.
Почти все проблемы, которые Вы описали решает IDE, ведь для этого она и нужна.
Ну и уж лучше возня с анбоксингом, чем с !==.