TDD: а ведь я не знаю типов возвращаемых функциями/методами данных

Читаю книгу Test-Driven Development with Python by Harry Percival. Она на примере использования фреймворка Django.

Там все построено примерно вот в таком ключе: а давайте напишем вот такой тест.

И потом объясняется, а вот, этот объект у нас такого типа, поэтому нам придется применить тут decode().

Вот давайте представим, что мы видим все эти объекты в первый раз. Это модель. И для меня - лично - она очень реальна. Ибо я постоянно сталкиваюсь с незнакомыми объектами.

Вот откуда я должен знать, что у объекта response есть свойство content? Какого оно типа? При программировании я обычно ставлю точку останова и смотрю, что прилетело. И от этого пляшу. Я и тут - в тесте - могу поставить точку останова и посмотреть, что прилетело. А по-другому я не могу. Теоретически можно рыть документацию. Но это не всегда помогает и насколько это трудоемко. Можно рыть код фреймворка - но тоже спорный момент. Точка останова гораздо быстрее дает возможность сориентироваться на местности.

Я никогда не видел TDD в реальной жизни. Все знакомые программисты не то что TDD, они и просто тесты-то не пишут.
По телевизору смотришь: мужик выступает и говорит, а я, говорит, не пользуюсь отладчиком. А зачем, говорит, у меня все в тестах.

Да, это что же такое. Либо это позерство, либо он пишет совсем простые вещи (что маловероятно в современных условиях).

Вы мне скажите, правильно ли я понимаю, что надо к тестам относиться попроще? Т.е. привык ставить точку останова и смотреть, что прилетело, так и делай при написании тестов. А если не можешь написать тест наперед, извините, придется в данном конкретном случае отказаться от TDD, написать продуктивный код и потом покрыть его тестами.

Был бы рад услышать ваше мнение на этот счет.

0

Я вижу рацоинальное зерно. Но не согласен про невозможность использования тестов. Вот книжку прохожу по тестированию - ничего пока про SOLID не нашел. Я пока не вижу связи.

Я всецело за культуру программирования. Но надо постепенно. Я пока изучил фреймворк до какого-то уровня. сейчас добью книжку по тестам, и все: на боевой проект. А солидом можно попозже заняться, я думаю.

А пока из культуры программирования в голове только:
1) Разбивать на логические кусочки, т.е. не городить огромных кусков кода. Если что-то огромное, значит, надо раздробить.
2) Классы имеют специализацию. Универсальных классов не надо.
3) DRY, и не хардкодить.
4) Стараться придерживаться конвенции по стилю программирования. Сюда же входит именование.
5) По возможности применять паттерны.
6) Ну, а дальше что-то из клиент-серверного. Как можно меньше запросов к серверу. Лучше за запросить за раз побольше, чем два раза запрашивать. Запрос медленый. И как можно меньше запросов к БД, ибо это самое медленное звено.

SOLID - ну, я бы попробовал. Но нужна нормальная книжка с упражнениями и примерами. И на подходящем ЯП.

0

Kifsif, ты уже на верном пути. Конкретных упражнений по SOLID ты не найдёшь, ибо это просто набор принципов, которых следует придерживаться.

Пункт №2 - один из принципов SOLID. Вот нарыл более вменяемое разъяснение. Оно с примера на C#, но, думаю, тебе будет понятно.

0

SOLID пока не впечатляет что-то.

А вот с TDD у меня проблема такая. Если есть заготовки, то я их что же выбросить должен? Ну, надо же пилить от зародыша самого и покрывать все тестами. Хорошо если библиотечка у тебя уже готова, и можно ее просто подключить.

А так-то кирпичики - обычная практика. Сохраняешь хорошие примеры себе для будущего использования. Это что же отказаться? Странно.

0

Ничего не понял. Что и зачем нужно выкидывать?

0

Есть готовые кусочки кода. Которые ты хозяйственно для себя сохранил. Ну, они где-то есть: либо ты знаешь, как их из готового проекта достать, либо просто в текстовом файлике они лежат. Либо ты их нашел на крутом сайте. В общем, готовый небольшой блочок кода для выполнения конкретной задачи.

Так вот, по TDD ты так делать не должен. Т.е. нельзя взять и вставить сразу кусок. Надо написать одну строчку, добиться предсказуемого падения теста, Потом дописать одно слово и ждать другого предсказуемого падения. И т.п. А вот взять и кусок вставить, даже если он тебе нравится - это противоречит принципам TDD.

И как-то от кирпичиков отказываться не хочется.

0

Kifsif, это именно то, от чего я тебя пытался предостеречь - тупой формализм вместо того, чтобы взять и сделать, возникают какие-то надуманные проблемы.

Такая последовательно действий TDD диктуется только для одной цели - заставить тебя написать тестопригодный код (если ты код ещё не написан).

Если код уже есть, то у тебя три варианта:
1) Не греть голову и использовать то, что уже есть (предпочтительно);
2) Переделать этот код, чтобы он стал тестопригодным;
3) Переделать этот код, чтобы он стал тестопригодным и покрыть его тестами;

0

У меня пока нет опыта. Я бы сказал, что третий вариант предпочтительнее.

0

В любом случае ничего выкидывать не нужно)

0

Сообщение от Usaga Но вот по поводу TDD я придерживаюсь мнения, что это - фанатизм и гипертрофированние хорошей иди. TDD заставляет тебя писать тестопригодный код, просто обязывает это делать. В этом его задумка. И это хорошо. Но тестопригодный код можно писать и без TDD, обкладывая тестами свой код позже и не абсолютно весь, а только тот, который ты хочешь. Это более реальный сценарий. Ибо программы не ради тестов пишутся и тратить время на тестирования всего и вся просто потому, что это "правильно" - глупо.

Ты однако не понимаешь, в чем реальный смысл TDD.

Сообщение от Usaga если ты делаешь мелкую/простую программу или дико торопишь, то нет смысла тратить время на тесты

И на SOLID тоже нет смысла тратить. И вообще ни на что. Быдлокодишь как бог, не счастье ли?

Сообщение от Kifsif И не факт, что еще применять будешь.

Это вообще фундамент. Если мы говорим об ООП, а не о функциональной парадигме.

Сообщение от Kifsif Так вот, по TDD ты так делать не должен. Т.е. нельзя взять и вставить сразу кусок. Надо написать одну строчку, добиться предсказуемого падения теста, Потом дописать одно слово и ждать другого предсказуемого падения. И т.п. А вот взять и кусок вставить, даже если он тебе нравится - это противоречит принципам TDD.

Чтобы не было таких вопросов, нужно понять философию. А не просто следовать заповеди "тест-падение-рефакторинг".

0

Сообщение от ct0r Чтобы не было таких вопросов, нужно понять философию. А не просто следовать заповеди "тест-падение-рефакторинг".

Слушай, ну, расскажи, как ты видишь. У тебя, допустим, новый клиент. Которому нужно почти то же самое, что предыдущему клиенту. По идее, можно допилить старый проект. Пусть старый проект хорошо покрыт тестами.

Как ты возьмешься за новый проект? С нуля или все-таки будешь допиливать имеющийся код?

0

Сообщение от Kifsif Как ты возьмешься за новый проект? С нуля или все-таки будешь допиливать имеющийся код?

Допиливать естественно. Какой смысл его делать с нуля? И причем тут это?

0

Спасибо. В общем, опыт нужен.

0