Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
tchingiz
ок,
не автоматический тест, а автоматически запускаемый тест после модификации кода.

а без автоматического запускания это тдд или нет?
Самое смешное, что при известно растягивании терминологии, любая разработка это TDD. Мы с самого начала хотим "чего-то" это уже можно рассматривать как "тест". Мы что-то делаем и прогоняем это через свой "тест" который держим в голове. Удовлетворяет? Не удовлетворяет? Меняем код и попутно подправляем "тест" который продолжаем держать в голове. Таким образом, мы всегда используем Test Driven Development, зачастую не замечая этого.
Но если мы хотим следовать не только духу TDD, но и его букве, то нам придется писать практические тесты. И ставить эти тесты на автомат.

И да, частенько написать действительно практически применимый тест бывает не проще чем написать то что этот тест должен тестировать. А если мы хотим сделать идеальное тестирование NP-полной проблемы то и вообще с тестом придется обломаться.
Поэтому-то TDD и не получил такого уж широкого распространения и так редко применяется.
14 июл 15, 02:33    [17888316]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
f#
Guest
White Owl
.

И да, частенько написать действительно практически применимый тест бывает не проще чем написать то что этот тест должен тестировать. А если мы хотим сделать идеальное тестирование NP-полной * то и вообще с тестом придется обломаться.
Поэтому-то TDD и не получил такого уж широкого распространения и так редко применяется.


С мой точки зрения идеальный тест это не тот который тестирует все возможные комбинации входов и выходов, а тот, под который проще написать правильный код чем не правильный.

Я думаю tdd е получил большого распространения потому, что:
* надо уметь их готовить - если писать плохие тесты то от них больше вреда чем пользы (например, если тестировать все сразу, то получается не тест,а "контрольная сумма" - по нему трудно понять какие требование не выполняется,а видел только, что есть какие-то изменения
* надо рефакторить под тесты
* реально внедряется tdd а автоматическое тестирование. В результате тесты пишутся после кода, на дизайн когда не влияют, не помогают в начальной разработке, не формулируют требований а просто фиксируют статус кво.
* по некоторым исследованиям тесты увеличивают время разработки на треть зато в 10 раз снижают плотность ошибок. На этапе разработки проще взять технический долг у будущего и отрапортовать что фича сделана, чем сделать ее качественно, но позже.
14 июл 15, 08:03    [17888440]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
Гхостик
Guest
f#
White Owl
Поэтому-то TDD и не получил такого уж широкого распространения и так редко применяется.

надо уметь их готовить
+1.
И научиться этому посложнее чем освоить ещё один язык продолжая писать на нем в привычном старом стиле.
Да ещё и эмоциональная составляющая: отложенное вознаграждение за приложенные сейчас усилия для большинства- слабая мотивация.
14 июл 15, 08:25    [17888463]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
ViPRos
Member

Откуда:
Сообщений: 9389
вощем, в простых случаях - тесты практически не нужны, а в сложных - практически невозможны
14 июл 15, 14:28    [17890310]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26171
ViPRos
вощем, в простых случаях - тесты практически не нужны, а в сложных - практически невозможны
а между простыми и сложными существует 100500 "оттенков" :)
14 июл 15, 14:44    [17890388]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
ViPRos
Member

Откуда:
Сообщений: 9389
skyANA
ViPRos
вощем, в простых случаях - тесты практически не нужны, а в сложных - практически невозможны
а между простыми и сложными существует 100500 "оттенков" :)

оттенки нас не волнуют
если на граничных точках теория дает сбой, то фигня это а не теория, так как граничные точки самые важные (и их всегда можно передвнинуть ближе к центру :)
14 июл 15, 14:49    [17890423]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
tchingiz
Member

Откуда:
Сообщений: 31955
f#
White Owl
.

И да, частенько написать действительно практически применимый тест бывает не проще чем написать то что этот тест должен тестировать. А если мы хотим сделать идеальное тестирование NP-полной * то и вообще с тестом придется обломаться.
Поэтому-то TDD и не получил такого уж широкого распространения и так редко применяется.


С мой точки зрения идеальный тест это не тот который тестирует все возможные комбинации входов и выходов, а тот, под который проще написать правильный код чем не правильный.

Я думаю tdd е получил большого распространения потому, что:
* надо уметь их готовить -

помнится монография Майерса Искусство тестирования программ
http://publ.lib.ru/ARCHIVES/M/MAYERS_Glenford_Dj/_Mayers_G.Dj..html#004
произвела большое впечатление
20 июл 15, 16:03    [17913593]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
tchingiz
Member

Откуда:
Сообщений: 31955
White Owl
tchingiz
ок,
не автоматический тест, а автоматически запускаемый тест после модификации кода.

а без автоматического запускания это тдд или нет?
Самое смешное, что при известно растягивании терминологии, любая разработка это TDD. Мы с самого начала хотим "чего-то" это уже можно рассматривать как "тест". Мы что-то делаем и прогоняем это через свой "тест" который держим в голове. Удовлетворяет? Не удовлетворяет? Меняем код и попутно подправляем "тест" который продолжаем держать в голове. Таким образом, мы всегда используем Test Driven Development, зачастую не замечая этого.
Но если мы хотим следовать не только духу TDD, но и его букве, то нам придется писать практические тесты. И ставить эти тесты на автомат.

ээээ, наверно, автоматически выполнить, сравнить и, наверное самое главное, автоматически прокукарекать если не прошел один из тестов.
мой test.cmd



rem версия приложения
app -ver >.app.txt
rem подсказка по юниттесту
app -? >>.app.txt

rem прямое использование SQLite провайдера
rem DataAdapter
app -sqlite -b >>.app.txt
rem DataReader
app -sqlite >>.app.txt

rem используем фабрику SQLite провайдера и абстрактный провайдер
rem DataAdapter
app -sqlite -db -b >>.app.txt
rem DataReader
app -sqlite -db >>.app.txt

rem используем абстрактный провайдер
rem DataAdapter
app -db -b >>.app.txt
rem DataReader
app -db >>.app.txt
не является ТДД
равно как и тулза для тестирования
using System.Data.SQLite провайдера от
Written by Robert Simpson (robert@blackcastlesoft.com)

не есть тдд

К сообщению приложен файл. Размер - 24Kb
20 июл 15, 16:18    [17913673]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
tchingiz
мой test.cmd
...
не является ТДД
TDD это не тест. TDD это метод разработки приложения. Твой тест не является TDD, он является тестом.
Если ты этот тест написал заранее, а теперь правишь свою app чтобы она удовлетворяла этому тесту - тогда можно будет говорить что ты используешь TDD.
20 июл 15, 16:49    [17913854]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
tchingiz
Member

Откуда:
Сообщений: 31955
ок


автор
не является ТДД
читать как
не удовлетворяет ТДД
эээ,
ну, для точности, сначал написал нулевую версию апп.
потом тест.
потом обновляю версию апп и запускаю тест, с возможным его дописыванием
20 июл 15, 17:50    [17914152]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
tchingiz
ок


автор
не является ТДД
читать как
не удовлетворяет ТДД
Нет. Квоть правильно: тест не является TDD.
TDD это технология, это цикл жизни проекта. Это не один отдельный тест и даже не группа тестов. Это правило по которому разрабатывается приложение.

tchingiz
эээ,
ну, для точности, сначал написал нулевую версию апп.
потом тест.
Ну значит все, ты уже нарушил технологию. Начинать надо было с тестов. А теперь уже усё.
21 июл 15, 00:23    [17915091]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
tchingiz
Member

Откуда:
Сообщений: 31955
White Owl
Ну значит все, ты уже нарушил технологию. Начинать надо было с тестов. А теперь уже усё.

вся жизнь пошла прахом.
))
о, это может спасти положение.
Пишешь спецификацию и генериш юниттесты, а потом пишешь код


Fastest

Fastest is a model-based testing tool. The tool receives a Z specification and generates in an almost automatic way, test cases derived from the specification. Currently, it only provides limited functionality for test case refinement into C and Java.
10 авг 15, 12:45    [17998227]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
kmaw
книги/статьи читал. но как-то не проникся. ... есть в этом подходе что-то мне нужное.

Начиная с определённого уровня, имхо, стоит проникаться на практике. Книги могут описать подход, но либо слишком просты, либо слишком завязаны на специфичный опыт их авторов, и попытка буквально применять приводит к провалу. Так что я давно предпочитаю подход "слышал вот об этом.. что из этого и как можно хорошо применить у меня".

White Owl
TDD это забавный зверек пригодный для расчетных задач. Но в большинстве случаев мы пишем что-то работающее с пользовательскими интерфейсами, а для этого чрезвычайно сложно создать автоматический тест. Поэтому и TDD распространения не получил.

Создать автоматический тест для интерфейса ничуть не сложнее, чем для расчётного модуля. Несильная распространённость TDD имхо вызвана в основном первой "D" - той, что driven. Дело в том, что категорическое требование создавать тесты перед разработкой годится только для хорошо формализованных областей - действительно, в частности, тех же расчётов и конверторов. Для большинства же применений это либо прямой путь к плохому дизайну - и многочисленным рефакторингам до приемлемого состояния - либо просто неудобно. Например, неудобно писать тест типа "заполни поле А и нажми кнопку Б" в тот момент, когда интерфейс ещё не спроектирован и контролы А и Б неизвестны. Если отойти от этого требования, например, в сторону подхода "прототип - тесты - рабочая версия", получается очень даже неплохо.

kmaw
именно то что есть "бизнес-логика" - та часть, которую надо неизбежно говнокодить

Неизбежного говнокода не существует. Существует молчаливое согласие программиста говнокодить в тех или других случаях.

kmaw
как тут это TDD имеет место быть?

Очень даже хорошо. Главное, что нужно понять - что хороший тест есть воплощение какого-либо требования к системе. Да, того требования, которое в теории пишут аналитики, управление требованиями итп. Та "бизнес-логика" по сути состоит из набора требований вида "при таких-то исходных система должна реагировать так-то" - значит, тест вносит эти исходные и проверяет реакцию. Всё просто.

ДохтаР
Я прошу прощения , но последние бестпрактисы гласят что мухи ( гуй ) отдельно , а котлеты ( бизнеслогика ) отдельно.
При таком подходе нет проблем использовать TDD для тестировани бизнеслогики. А Гуй пусть оценивает комиссия по эстетике и морали,

Видите ли, ожидания пользователя от системы формулируются примерно так: "Я ввёл текст, нажал на кнопку - и письмо отправилось". Вы можете великолепно протестировать модуль smtp, но если "текст" оказался read-only, или кнопка не нажимается, или нажимается, но не вызывает нужную smtp-операцию - это провал. Функция не работает, пользователь недоволен, автоматическое тестирование провалилось, программист дурак.

Конечная цель автотестов - дать разработчику здоровую уверенность в том, что работа системы соответствует ожиданиям (требованиям) пользователей (заказчика). И интегральный тест "под ключ" - а в большинстве случаев это значит через интерфейс - такую уверенность даёт. Тестирование только некоторых звеньев (например, бизнес-логики) - не даёт. Поэтому тестирование гуя - и бизнес-логики через гуй - сугубо обязательно. Тестирование бизнес-логики отдельно - может быть дополнительным блоком, позволяющим проверить разные хитрые случаи проще и быстрее, чем тысячу раз повторяя их через гуй - но уже опционально.

MasterZiv
Если вы делаете софт как сервис, там и тесты не всегда и вдруг будут, и возможно писать их не нужно вообще, из экономических соображений -- легче и быстрее ошибку исправить и выкатить новую версию, чем создавать тесты.

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

egorych
И вот что я не понимаю возвращаясь, всё же, к заявленной теме - как тут применить TDD, когда программируешь такие кейсы. А ведь именно здесь они и нужны больше всего.

Так и применить. Ввести даты, нажать кнопку и проверить, что строка стала красного цвета. В чём проблема?

F#
Это надо обосновать - почему тестирование только отдельных кусков херит всю идею.

Это обосновали почти пятьдесят лет назад, когда провели исследование и обнаружили, что основная тяжесть ошибок в программах приходится не на "отдельные куски", а на их взаимодействие.

F#
Например в электрический чайник я наливаю воду вручную, но дальше он кипятит чай самостоятельно. Если он облегчает мне часть работы почему бы его не использовать?

В самом деле. Пару месяцев назад моя жена купила электрический чайник. У него оказалась клёвая фича - после того, как он вскипятил воду, он не отщёлкивает кнопку, а просто термореле отключает спираль. Минут через пятнадцать он снова включается и снова доводит воду до кипения. И так далее. Вы берёте его, тестируете кусок, вставляете в квартиру - и уезжаете, рассчитывая к возвращению иметь чайник кипячёной воды. А приезжая, обнаруживаете в лучшем случае пустой чайник, а в худшем - пожар. Профит кусочного тестирования!

F#
абстрагировать UI - объекту отвечающему за бизнес логику подсовывать симуляцию пользовательского ввода, который в ответ на конкретный вопрос выдает заранее записанный ответ.

Замечательный способ сделать огромную кучу работы, которая так ничего и не гарантирует. Всего лишь вместо вопроса "правильно ли один вывод подсовывается в интерфейс" останется вопрос "правильно ли другой вывод подсовывается в интерфейс".

ViPRos
а как проверить - правильно ли мой метод рассчитал расписание работ на 50 станков на месяц на 10000 работ?

По требованиям, которые выдвигались к математике метода. В общем так же, как Вы сейчас проверяете вручную - "на одно время и один станок не назначено две разных работы? время простоя меньше 5%? ... все критерии соблюдены? значит, правильно рассчитал"

ViPRos
правильный ли я СКЛ генерирую по модели?

А вот это - яркий и классический пример того, чего вообще не надо проверять. Именно наделав таких тестов, ламеры начинают кричать, что TDD - дерьмо.

Проверять нужно то, что некий модуль возвращает нужные результаты (и не возвращает ненужных). А генерит ли он внутри себя SQL так, или иначе, или не генерит, а пользуется готовыми, или выгребает всё позаписно и сращивает-фильтрует внутри себя или как угодно ещё - это наплевать, это его внутренняя кухня.

Посмотрите выше про отправку письма. Пользователя интересует сценарий типа "я вбил получателя "Вася", текст "Ты козёл", нажал кнопку "Отправить" - у Васи всплыло "Ты козёл". Именно этот сценарий и нужно проверять тестом. А реализован ли он через smtp, или через icq, или через sql - пользователю наплевать.

ViPRos
хе, взяли тут прогера тира он будет писать автотесты
от он пытается проверить - правильную ли форму сгенерировала прога :)

Значит, он дурак. Выгоняйте и берите того, кто умеет писать тесты. Не нужно проверять, какую форму сгенерировала прога. Нужно проверять, выполняет ли эта форма те действия, которые от неё требуются.

ViPRos
(а про эффективность воще молчу - расписание можно считать 10 часов и 2 минуты,

Лучше не молчать, а думать. Выкатываете требование считать расписание две минуты - значит, вставьте в тест проверку "время расчёта больше двух минут". Вот не поверю, что это Вам не по силам :)

ViPRos
СКЛ может быть компактным или 7этажным)

А вот на это снова наплевать. Если модуль генерирует SQL - тот должен быть правильным (с точки зрения результатов во всяких ситуациях) и эффективным (с точки зрения выполнения в БД). Ставя критерием компактность - Вы в лучшем случае занимаетесь фигнёй, в худшем - портите программу.

ViPRos
раньше все проги сдавались на тестовом примере (контрольном), так вот проги кроме этого и не умели ничего так что проехали это лет 40 назад

Да, студенты так делали. А те, кто выросли дальше студентов, знают, что тогда же придумали и простой метод против таких прог: разработчику выкатывали один набор контрольных примеров, а реальную приёмку делали на аналогичном, но другом.

F#
Многие считают, что основная ценность тестов не собственно в проверке функциональности, а в проверке дизайна: Если трудно писать модульные тесты, значит модели плохо изолированы друг от друга и надо рефакторить.

Вот как раз модульными тестами не стоит увлекаться. Это отличный способ потратить неограниченное количество ресурсов с минимальной пользой для проекта.

White Owl
Самое смешное, что при известно растягивании терминологии, любая разработка это TDD. Мы с самого начала хотим "чего-то" это уже можно рассматривать как "тест".

Именно так. "Хотим" - это requirement. Тест - это запрограммированная проверка requirement-а. Именно поэтому автоматические тесты позволяют нам в любой момент понять, насколько система отвечает ожиданиям заказчиков, то есть по сути насколько она близка к завершению разработки. С позиций экстремала-теоретика можно сказать, что набор формализованных требований надо сразу перевести в набор тестов, а далее в тот момент, когда все тесты покажут зелёную галочку - остановить работу и подписать акт сдачи в эксплуатацию.

White Owl
И да, частенько написать действительно практически применимый тест бывает не проще чем написать то что этот тест должен тестировать.

Это в общем не страшно. По моему опыту, хороший тест - даже из тех, что "не проще написать" - окупается уже к моменту сдачи в эксплуатацию, не говоря уже о выгодах во время сопровождения.
20 авг 15, 13:55    [18045707]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4742
softwarer
egorych
И вот что я не понимаю возвращаясь, всё же, к заявленной теме - как тут применить TDD, когда программируешь такие кейсы. А ведь именно здесь они и нужны больше всего.
Так и применить. Ввести даты, нажать кнопку и проверить, что строка стала красного цвета. В чём проблема?
руками это протестировать - проблем нет, проблема в автоматизации таких тестов.
Однако, мне понравилась вот эта мысль:
softwarer
Несильная распространённость TDD имхо вызвана в основном первой "D" - той, что driven. Дело в том, что категорическое требование создавать тесты перед разработкой годится только для хорошо формализованных областей - действительно, в частности, тех же расчётов и конверторов. Для большинства же применений это либо прямой путь к плохому дизайну - и многочисленным рефакторингам до приемлемого состояния - либо просто неудобно. Например, неудобно писать тест типа "заполни поле А и нажми кнопку Б" в тот момент, когда интерфейс ещё не спроектирован и контролы А и Б неизвестны. Если отойти от этого требования, например, в сторону подхода "прототип - тесты - рабочая версия", получается очень даже неплохо.
буду её обдумывать.
20 авг 15, 14:59    [18046217]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
egorych
руками это протестировать - проблем нет, проблема в автоматизации таких тестов.

Скажу так: уже лет двадцать как мне не приходилось работать с инструментами, где автоматизировать подобный тест было бы серьёзной проблемой. Наверное, такие ещё сохранились, но я с ними как-то не сталкивался.
20 авг 15, 15:30    [18046477]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4742
softwarer
Скажу так: уже лет двадцать как мне не приходилось работать с инструментами, где автоматизировать подобный тест было бы серьёзной проблемой.
дело не в инструментах, конечно =))
20 авг 15, 15:40    [18046573]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
White Owl
Самое смешное, что при известно растягивании терминологии, любая разработка это TDD. Мы с самого начала хотим "чего-то" это уже можно рассматривать как "тест". Мы что-то делаем и прогоняем это через свой "тест" который держим в голове. Удовлетворяет? Не удовлетворяет? Меняем код и попутно подправляем "тест" который продолжаем держать в голове. Таким образом, мы всегда используем Test Driven Development, зачастую не замечая этого.

Это слишком обобщённо. Этак можно сказать, что любой школьник использует TDD, когда только собирается начать писать программу и хочет чтобы его будущая софтина была супер-пупер. Нет, о тестах он ещё не знает, но в голове держит: "моя прога - самая крутая". Это - не TDD.
20 авг 15, 17:23    [18047415]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
На мой взгляд, главный миф о TDD - то, что тесты нужно писать раньше кода. Это теоретически невозможно!
Сейчас обосную!

В мелких статейках и бложиках многие программеры, едва познакомившиеся с юнит-тестированием, нахватавшись разных (глупых) идей, начинают кукарекать: сперва тесты, потом код!
Но ни в одной серьёзной нормальной большой статье, а тем более в книгах по тестированию я не встречал такой бред. Если кто знает такую книгу - упомяните.

Да, мне неоднократно пытались доказать, что они сперва пишут тесты, а потом код. При внимательном изучении всегда оказывалось, что это не так. Возможны два случая:
1. В прошлом этот разработчик уже писал похожий код в подобном проекте; поэтому в нынешнем проекте он автоматически переносит куски кода оттуда; в таком случае действительно можно сперва написать тесты, а потом код; но на самом-то деле код уже был написан ранее!
2. Сперва ведётся тщательнейшее проектирование, расписывается до мелочей взаимодействие модулей, всё чуть ли не до локальных переменных определено. Пример такого проектирования описан в книге Крэга Лармана "Применение UML и шаблонов проектирования". Дальнейшая работа сводится к тупому кодированию. Вот теперь, после проектирования, можно написать тесты, а потом код. Но тесты не были первыми! Сперва был проект!

Одной из культовых книг считается "Рефакторинг" Фаулера. Если её почитать, то он по ходу повествования постоянно переносит код из одного метода в другой, потом в другой класс, выносит параметры в поля, потом обратно, через несколько итераций возвращает метод в первоначальный класс, но уже с другими параметрами... Вот как тут писать тесты? Написал и тут же выкинул.
Да, если мы не уверены, что в процессе рефакторинга ничего не сломаем, то сперва нужно написать тесты. Но это на уже работающий код. А если код ещё не работает, даже не компилируется, если мы ищем способ как вообще его написать - о каких тестах может идти речь? А если тесты всё же очевидны, тот тут смотри выше два описанных случая: либо похожий проект писался раньше и поэтому код (большая его часть) заранее известен, либо было проведено тщательное проектирование (сперва проект - затем тест и тупое кодирование).

Или вот, например, презенташка http://blacksheep.parry.org/wp-content/uploads/2010/03/State-of-the-Art-Testability.ppt (Java)
Изначально было три класса. Постепенно, в ходе рефакторинга кода для улучшения тестирования (а также уменьшения связности, внедрения зависимостей и пр.) классов стало восемь. Нужно ли было писать тесты на первые три класса? При условии, что вся эта работа по написанию кода была проведена за один день? Имхо, это бессмысленно, да и невозможно: в первой версии методы внутри себя создают другие классы и их нельзя подменить/замокать.

Можно ли было написать сразу конечную версию с восемью легко тестируемыми классами? Можно! При этом сперва можно (и нужно) написать тесты. Казалось бы, я противоречу сам себе (смотрите тезис в первом абзаце). Но дело в том, что чтобы дойти до такого дизайна нужно сперва наломать кучу дров, написать тысячи строк хрупкого сильносвязанного кода, набить шишки. То есть сперва - код! И лишь затем, по прошествии месяцев или лет, набравшись опыта, научиться сходу проектировать легкотестируемый код. То есть, опять же: вначале по-любому будет код - в голове разработчика, код из предыдущих проектов, из опыта. А тесты - потом.
20 авг 15, 17:53    [18047675]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 55542
Блог
petalvik
Одной из культовых книг считается "Рефакторинг" Фаулера. Если её почитать, то он по ходу повествования постоянно переносит код из одного метода в другой, потом в другой класс, выносит параметры в поля, потом обратно, через несколько итераций возвращает метод в первоначальный класс, но уже с другими параметрами... Вот как тут писать тесты? Написал и тут же выкинул.

На самом деле писать их довольно просто :) Ситуация, когда в ходе рефакторингов постоянно ломаются тесты, означает типичную ошибку их написания - тесты, слишком погруженные в реализацию.

Хороший тест работает выше уровнем, он проверяет требование к проекту. Как следствие, он меняется вместе с требованиями и в минимальной степени зависит от реализации. Идея инкапсуляции говорит нам, что у объекта есть интерфейс и реализация - так вот, тест работает на уровне интерфейса, причём как правило у довольно высокоуровневых объектов. И вся эта мышиная возня в реализации его не касается; разработчик может выделять методы, классы, переименовывать, объединять, менять алгоритмы - а тест проверяет, что если подать на вход "2*2", на выходе будет "4".

petalvik
Изначально было три класса. Постепенно, в ходе рефакторинга кода для улучшения тестирования

"Рефакторинг для улучшения тестирования" уже означает кривизну тестирования. Можно дальше не смотреть.
20 авг 15, 18:25    [18047845]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
softwarer
На самом деле писать их довольно просто

Халва, халва...

:) Ситуация, когда в ходе рефакторингов постоянно ломаются тесты, означает типичную ошибку их написания - тесты, слишком погруженные в реализацию.

softwarer
Хороший тест работает выше уровнем, он проверяет требование к проекту.

О как! Юнит-тесты не считаем?

softwarer
Как следствие, он меняется вместе с требованиями

Заказчик просит: сделать зашибись! Напиши тест.
Я ж говорю: сперва тщательное проектирование, обсуждение с заказчиком, выявление этих самых требований, потом тест. Но не сперва тест, а потом всё остальное.

softwarer
и в минимальной степени зависит от реализации.

Банальный калькулятор. Должен считать 2*2. Идея инкапсуляции говорит нам, что у объекта есть интерфейс и реализация - так вот, тест работает на уровне интерфейса, причём как правило у довольно высокоуровневых объектов. И вся эта мышиная возня в реализации его не касается; разработчик может выделять методы, классы, переименовывать, объединять, менять алгоритмы - а тест проверяет, что если подать на вход "2*2", на выходе будет "4".

petalvik
Изначально было три класса. Постепенно, в ходе рефакторинга кода для улучшения тестирования

"Рефакторинг для улучшения тестирования" уже означает кривизну тестирования. Можно дальше не смотреть.[/quot]
20 авг 15, 18:44    [18047954]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
petalvik
На мой взгляд, главный миф о TDD - то, что тесты нужно писать раньше кода. Это теоретически невозможно!
Сейчас обосную!
Миф? Обосновывать? Учи матчасть! В смысле читай оригинал.

petalvik
Но ни в одной серьёзной нормальной большой статье, а тем более в книгах по тестированию я не встречал такой бред. Если кто знает такую книгу - упомяните.

ISBN 9780321146533
20 авг 15, 18:45    [18047961]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
White Owl
Member

Откуда:
Сообщений: 12349
petalvik,

И вообще, ты можешь конечно спорить с удобством и практичностью TDD, но ты никак не можешь спорить о том что это есть такое.
20 авг 15, 18:48    [18047974]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
Прошу прощения. Модератор, удали, пожалуйста, предыдущее сообщение.

softwarer
На самом деле писать их довольно просто

Халва, халва...
Да, тесты писать легко. Если уже известна архитектура. А откуда она известа? Из опыта предыдущей работы, из опыта написания тысяч строк кода ранее.

softwarer
Хороший тест работает выше уровнем, он проверяет требование к проекту.

О как! Юнит-тесты не считаем?

softwarer
Как следствие, он меняется вместе с требованиями

Заказчик просит: сделать зашибись! Напиши тест.
Я ж говорю: сперва тщательное проектирование, обсуждение с заказчиком, выявление этих самых требований, потом тест. Но не сперва тест, а потом всё остальное.

softwarer
и в минимальной степени зависит от реализации.

Банальный калькулятор. Должен считать 2*2. Какого типа параметры должны быть: int, double, что-то ещё? Если ты сразу можешь это сказать, значит или имеется предыдущий опыт написания похожих проектов (код!!!) или сперва было проведено проектирование.

softwarer
"Рефакторинг для улучшения тестирования" уже означает кривизну тестирования. Можно дальше не смотреть.
В том-то и дело, что сперва было:
softwarer
тесты, слишком погруженные в реализацию
Любой джуниор напишет именно такой код, как в начале. Принципиално нетестируемый.
Мне не сложно, я повторю ещё раз: если разработчик может сходу написать легкотестируемый код, значит за плечами у него несколько лет работы и куча реализованных проектов. Вот на основе кода тех проектов и можно сперва писать тесты.
20 авг 15, 18:51    [18047989]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
White Owl
petalvik,

И вообще, ты можешь конечно спорить с удобством и практичностью TDD, но ты никак не можешь спорить о том что это есть такое.


Прочти внимательно то, что я написал.
Я не спорю с TDD, я сам его использую.

Я оспорил один тезис: то, что сперва пишутся тесты, а потом код.
20 авг 15, 18:53    [18047998]     Ответить | Цитировать Сообщить модератору
 Re: Про TDD  [new]
petalvik
Member

Откуда:
Сообщений: 673
White Owl
ISBN 9780321146533

Раздел "Вначале тест (Test First)".
Пример кода оттуда:
Buffer reply = reader.contents();
assertTrue(reader.isClosed());

Сразу возникает вопрос: откуда автор знает, что после выполнения метода reader.contents() сокет закрывается? Значит, он уже писал код (вначале - код!), использующий сокеты, значит штудировал документацию по сокетам (вначале - проектирование!). И лишь потом - тест.

Я повторю в очередной раз: когда гуру программирования и проектирования пишет сперва тест на ещё несуществующий код, это значит, он уже писал ранее похожий код.
20 авг 15, 19:09    [18048065]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Программирование Ответить