TDD и вообще юнит-тесты in the wild
Locked
1234
1234
TDD и вообще юнит-тесты in the wild
 
|
Я уже поднимал этот вопрос раньше, но ясность у меня так и не появилась.
-- Вопрос вот какой: как использовать юнит-тестирование, и тем более TDD - в реальной жизни, а не на абстрактных примерах? Я умею работать с SUnit, более того - я весьма успешно использовал даже и TDD. Но только в очень специальных случаях. Например, мне нужно было написать калькулятор судебной пошлины с множеством довольно дурацких правил и со странным округлением. Там так и просился TDD - и очень помог. Nile, система для "безопасной арифметики", очень хорошо и удобно покрывается тестами. Но такой работы, может, 5%-10% от общего вала. Как применить TDD или хотя бы вообще тесты к остальным 90% ? Чтобы быть более конкретным - возьмём тот самый Tabular. Движок для импорта-экспорта таблиц из/в распространённые форматы. Как его разрабатывать с помощью TDD? Этот движок состоит, очевидно, из внутренней модели представления табличных данных. Эту модель, конечно, легко покрыть тестами и легко разрабатывать с помощью TDD. Понятно даже, что применение TDD поможет выделить и держать работоспособными используемые интерфейсы. Но понятно также, что основная польза, основной полезный код - это именно импортеры-экспортеры. Как применить TDD к ним? Я не знаю. Конечно, под TDD замечательно легла задача "пересчитать номер колонки в её буквенный код". A, B, C, ..., Z, AA, AB, .... и так далее. Но дальше? -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
CONTENTS DELETED
The author has deleted this message.
|
Re: TDD и вообще юнит-тесты in the wild
|
|
Ну вот смотри: сейчас там реально генерируется XLSX. Который представляет из себя набор зазипованных XML'ек. XMLWriter смысла тестировать нет - он и так покрыт тестами очень хорошо. ZIPArchiver тоже. Они свою работу сделают. А "свои ожидания" описываются словами "должно нормально открыться в Excel". При этом соответствие текста XMLек образцу "с точностью до символа" не требуется. Если у тега будут идти те же параметры, но в другом порядке - это нормально и приемлемо. И что делать? 26 ноября 2014 г., 16:48 пользователь Vladimir Musulainen <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму XML на выходе. Вот это и тестируется. Создаешь ХМL содержащий информацию априори тебе известную. Архивируешь. Потом в обратно порядке: разархивируешь, читаешь XML Reader дату ожидая увидеть правильную последовательность, которая насколько тебе это известно должна отрываться в Excel. Формат исходных данных надо разнообразить в тех пределах, какие ты можешь ожидать в реальной работе. 2014-11-26 6:13 GMT-08:00 Юрий Мироненко <[hidden email]>: > Ну вот смотри: сейчас там реально генерируется XLSX. > Который представляет из себя набор зазипованных XML'ек. > > XMLWriter смысла тестировать нет - он и так покрыт тестами очень хорошо. > ZIPArchiver тоже. Они свою работу сделают. > > А "свои ожидания" описываются словами "должно нормально открыться в Excel". > При этом соответствие текста XMLек образцу "с точностью до символа" не > требуется. > Если у тега будут идти те же параметры, но в другом порядке - это нормально > и приемлемо. > > И что делать? > > 26 ноября 2014 г., 16:48 пользователь Vladimir Musulainen > <[hidden email]> написал: > >> Я до начала имплементации пишу тест, в котором я описываю свои ожидания, >> что-то типа >> >> CSVExporter export: data to: writeStream. >> self assert: writeStream contents = >> ‘value1;value2;value3<n>value4;value5;value6<n>’ expandMacros. >> >> А потом добиваюсь, чтобы export:to: отработал как надо. >> >> >> 26 нояб. 2014 г., в 16:29, Юрий Мироненко <[hidden email]> >> написал(а): >> >> Я уже поднимал этот вопрос раньше, но ясность у меня так и не появилась. >> Вопрос вот какой: как использовать юнит-тестирование, и тем более TDD - в >> реальной жизни, а не на абстрактных примерах? >> >> Я умею работать с SUnit, более того - я весьма успешно использовал даже и >> TDD. Но только в очень специальных случаях. Например, мне нужно было >> написать калькулятор судебной пошлины с множеством довольно дурацких правил >> и со странным округлением. Там так и просился TDD - и очень помог. Nile, >> система для "безопасной арифметики", очень хорошо и удобно покрывается >> тестами. >> >> Но такой работы, может, 5%-10% от общего вала. >> Как применить TDD или хотя бы вообще тесты к остальным 90% ? >> >> Чтобы быть более конкретным - возьмём тот самый Tabular. >> Движок для импорта-экспорта таблиц из/в распространённые форматы. >> Как его разрабатывать с помощью TDD? >> >> Этот движок состоит, очевидно, из внутренней модели представления >> табличных данных. >> Эту модель, конечно, легко покрыть тестами и легко разрабатывать с помощью >> TDD. >> Понятно даже, что применение TDD поможет выделить и держать >> работоспособными используемые интерфейсы. >> >> Но понятно также, что основная польза, основной полезный код - это именно >> импортеры-экспортеры. >> Как применить TDD к ним? >> Я не знаю. >> >> Конечно, под TDD замечательно легла задача "пересчитать номер колонки в её >> буквенный код". A, B, C, ..., Z, AA, AB, .... и так далее. >> Но дальше? >> >> >> -- >> -- >> http://groups.google.ru/group/sugr >> --- >> Вы получили это сообщение, поскольку подписаны на группу "Russian >> Smalltalk User Group". >> Чтобы отменить подписку на эту группу и больше не получать от нее >> сообщения, отправьте письмо на электронный адрес >> [hidden email]. >> Чтобы настроить другие параметры, перейдите по ссылке >> https://groups.google.com/d/optout. >> >> >> -- >> -- >> http://groups.google.ru/group/sugr >> --- >> Вы получили это сообщение, поскольку подписаны на группу "Russian >> Smalltalk User Group". >> Чтобы отменить подписку на эту группу и больше не получать от нее >> сообщения, отправьте письмо на электронный адрес >> [hidden email]. >> Чтобы настроить другие параметры, перейдите по ссылке >> https://groups.google.com/d/optout. > > > -- > -- > http://groups.google.ru/group/sugr > --- > Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk > User Group". > Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, > отправьте письмо на электронный адрес [hidden email]. > Чтобы настроить другие параметры, перейдите по ссылке > https://groups.google.com/d/optout. -- -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group. Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Настройки подписки и доставки писем: https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
In reply to this post by Yuriy Mironenko
Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Поэтому постараюсь быть краток. (Перечитав то, что получилось, добавлю: насколько смогу:) Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. За первый вариант мне сказать нечего. Если же мы хотим разрабатывать (именно TDD), то надо решить, с какого момента мы хотим TDD. "Классический" TDD как его описал Кент Бек предполагает некую стадию предварительного проектирования вне рамок TDD. Это примерно то, что предложил Владимир: мы уже где-то как-то придумали какие должны быть объекты, какая к ним приписана функциональность и используем TDD чтобы эту функциональность уточнить и зафиксировать. Не могу сказать, что это не работает — очень даже хорошо работает, но именно в тех рамках, в которых применяется. То есть, если впоследствии оказывается, что предварительный дизайн был не слишком удачным, то придется переделывать и переделывать все — не только основной код, но и тесты. У меня в реальной жизни часто так и получается… слишком часто. Поэтому я стараюсь придерживаться "чистого" TDD, где стадия проектирования не выносится "за скобки". Для меня это работает гораздо лучше — именно в плане дизайна. Но и дизайн получается несколько… специфический… В общем, для тех, кто привык руководствоваться априорными правилами хорошего дизайна, результат выглядит "не очень" (обычно речь идет об избыточной сложности)… Но работает! И сложность оказывается либо не настолько уж избыточной, либо (даже чаще) очень уместной. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени. И по поводу ожиданий… Здесь, похоже, как раз сказывается отношение к TDD как к способу тестирования. Да, Excel сможет "скушать" разные варианты файлов, но ваш конвертер для конкретного входа будет выдавать какой-то один вариант (если вы не хотите использовать генератор случайных чисел). И вам нужно не описать все правильные варианты, а просто реализовать какой-то один из них. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. На всякий случай уточню: это если "по классике" — с середины начинать :) -- Best regards, Dennis Schetinin 26 ноября 2014 г., 18:13 пользователь Юрий Мироненко <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
In reply to this post by Alex Kogan
Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
-- Но идея об использовании "XML-читалки" в любом случае полезная, спасибо. 26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал: Ну надо полагать, что некие известные тебе стандартные входные данные -- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
Это будут именно юнит-тесты. -- Best regards, Dennis Schetinin 28 ноября 2014 г., 12:54 пользователь Юрий Мироненко <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
Денис, это был ответ на письмо Когана. Ответ тебе ещё надо сочинить :) 28 ноября 2014 г., 12:15 пользователь Dennis Schetinin <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
:) Пардон -- Best regards, Dennis Schetinin 28 ноября 2014 г., 13:26 пользователь Юрий Мироненко <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
У TDD есть один "довесок" напрямую не относящийся к нему. TDD содержит тесты, в которых используются готовые решения (примеры). Например, осваивал MongoTalk именно по тестам. 28 ноября 2014 г., 16:23 пользователь Dennis Schetinin <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
Это да, тесты - весомый довесок к "самокомментирующемуся коду". 28 ноября 2014 г., 14:03 пользователь Nikolay Kleptsov <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
In reply to this post by Dennis Schetinin
Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Вообще, я всегда не прочь прочитать нечто длинное и якобы занудливое, если там подробно раскрывается тема. Я люблю читать, разбираться и разгребать. Долой клиповое сознание! :) Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Поправь меня, если я ошибаюсь, но ведь в итоге мы приходим к коду, покрытому тестами, в котором тесты играют ту же роль, что юнит-тесты при обычном подходе? То есть, помогают контролировать целостность реализации при последующих модификациях. Или такие тесты потом нужно ещё писать отдельно? Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. Лично я для начала хочу понять, как _вообще_ можно писать тесты к основной массе встречающихся на практике задач, да ещё так, чтобы от этого была какая-то польза. Пока я этого не понимаю. Не понимая этого я, конечно, не могу понять и TDD. То есть я его понимаю в той части, где тесты хорошо пишутся - и в таком разе я могу воспользоваться как TDD, так и написать тесты к уже готовому коду. Но для основной массы кода это просто не работает. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. Ну смотри. Допустим, я "специфицировал вплоть до символа", что параметры какого-то тега должны идти в таком-то порядке. А XML-фреймворк решил, что он выдаст мне параметры тега в алфавитном порядке. Меня это устроит, а написанные тесты - будут ругаться. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени. Интерес - и крайне сильный - есть. Недаром же я периодически поднимаю эту тему. Предлагаю сделать так: Я начал делать XLSX-экспортёр. За ODS-экспортёр я ещё даже не брался. Поскольку эти задачи очень и очень похожи друг на друга, имеет смысл XLSX-экспортёр продолжать делать "по старинке", а ODS-экспортёр начать делать с помощью TDD. Тогда будет наглядно видна разница между подходами. Если такой план тебе нравится - с чего начать? 27 ноября 2014 г., 8:37 пользователь Dennis Schetinin <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
>> Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. > Поправь меня, если я ошибаюсь, но ведь в итоге мы приходим к коду, покрытому тестами, в котором > тесты играют ту же роль, что юнит-тесты при обычном подходе? То есть, помогают контролировать > целостность реализации при последующих модификациях. > Или такие тесты потом нужно ещё писать отдельно? Тесты, которые будут созданы в процессе TDD, разумеется, можно использовать и для тестирования. Но в процессе разработки мы пишем такие тесты, таким образом и ровно столько, чтобы разработать нужную функциональность. "Покрытие" тестами с целью всесторонней проверки ПО — совсем другая задача. Соответственно, там и тесты с методами их создания чуть-чуть другие, и "чем больше, тем лучше"… Впрочем, я не специалист в области тестрирования. >> Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. > Лично я для начала хочу понять, как _вообще_ можно писать тесты к основной массе встречающихся > на практике задач, да ещё так, чтобы от этого была какая-то польза. Пока я этого не понимаю. Тогда, возможно, нет смысла лезть в дебри всяческих моков, подходов "сверху-вниз" и т.п. — достаточно ограничиться классическим вариантом. Книжка Бека про TDD прочитана? Там примеры вполне из жизни… > Ну смотри. Допустим, я "специфицировал вплоть до символа", что параметры какого-то тега должны идти > в таком-то порядке. А XML-фреймворк решил, что он выдаст мне параметры тега в алфавитном порядке. > Меня это устроит, анаписанные тесты - будут ругаться. Ну, измени тест. Если поумничать, то можно сказать так: TDD — это способ разработки через исследование. С целью создания нужного софта исследуются требования, понимание правильности, имеющийся код и т.д. В данном случае речь как раз о требованиях и правильности. > Я начал делать XLSX-экспортёр. За ODS-экспортёр я ещё даже не брался. > Поскольку эти задачи очень и очень похожи друг на друга, имеет смысл XLSX-экспортёр продолжать делать > "по старинке", а ODS-экспортёр начать делать с помощью TDD. Тогда будет наглядно видна разница между > подходами. > Если такой план тебе нравится - с чего начать? Раз, как я понимаю, "архитектура" уже выработана на случае XLSX, то этот вопрос не поднимаем. В этом случае я бы записал в виде теста самый простой случай: пустой файл. Я бы сгенерировал этот самый пустой файл, чтобы достать строку, которую он содержит. Она, возможно, будет не очень короткая, так что я бы ее в отдельный метод вытащил (expectedEmptyFileString). Еще предполагаю, что экспортер работает с каким-то потоком, соответственно проверка условия идет через буфер. Тогда получится так (распишу прямо по шагам — так логику легче отследить): 1) OdsExportTests >> testEmpty 2) OdsExportTests >> testEmpty actualString should equal: self expectedEmptyFileString 3) OdsExportTests >> testEmpty actualString := String new. actualString should equal: self expectedEmptyFileString 4) OdsExportTests >> testEmpty actualString := String new. exporter := OsdExporter newOn: (WriteStream on: actualString). exporter export. actualString should equal: self expectedEmptyFileString Примерно так выходит… -- Best regards, Dennis Schetinin 30 ноября 2014 г., 14:32 пользователь Юрий Мироненко <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
Книжка Бека про TDD прочитана? Там примеры вполне из жизни… Нет, книжка не прочитана. Раньше я эту книжку не видел и о ней не знал. Скачал, прочитаю. По результатам беглого просмотра: как сделать на TDD то, что там приводится в качестве примера (там единственный пример - или имелась в виду не та книжка? Я говорю про "Tesd-driven development by example" - и там в качестве примера приводится то ли мультивалютный кошелек, то ли что-то в таком роде), я знаю и сам. И даже имею соответствующий и вполне успешный опыт. Но это, как я и жаловался выше, от силы 10% в обычном объёме работы. Типичная задача, например: "хочу, чтобы в справочнике клиентов было место рождения, и чтоб оно отражалось в печатных формах А и Б". Вот как такое затестить - я не знаю. Точнее не так: я знаю, как теоретически можно было бы написать соответствующие тесты. Однако это будет что-то абсолютно, совершенно уродское и, по всей видимости, бесполезное. Код будет существенно сложнее реализации, и будет содержать ту же логику, что и сама реализация, только в вывернутом виде. Если верить http://habrahabr.ru/post/112851/ - это серьёзные ошибки. Это, не знаю, как тестировать аксессоры. Никто не тестирует аксессоры. Вот здесь у человека те же проблемы, что и у меня: http://habrahabr.ru/post/113487/#comment_3646619 Что интересно, ответы, которые давали ему на хабре, очень похожи на те, которые я получаю здесь. Некоторые прямо текстуально совпадают. P.S. Про "рекомендации о первых шагах" я напишу отдельно. 1 декабря 2014 г., 9:03 пользователь Dennis Schetinin <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
In reply to this post by Dennis Schetinin
Раз, как я понимаю, "архитектура" уже выработана на случае XLSX, то этот вопрос не поднимаем. Не очень-то она выработана, там proof-of-concept. Показывает возможность и основные приёмы работы, архитектурой там и не пахнет. Большая часть файлов вообще как строчки захардкожены. В этом случае я бы записал в виде теста самый простой случай: пустой файл. Не вполне понятно, что такое этот "пустой файл". Это workbook без worsheet'ов? Или это workbook с одним пустым worsheet'ом? Или это то, что создаётся в офисном пакете, когда нажимаешь "Файл-Новый"? Обычно содержит три пустых worksheet'а. Или неважно, и я могу выбрать любой? Я бы сгенерировал этот самый пустой файл, чтобы достать строку, которую он содержит. Она, возможно, будет не очень короткая, так что я бы ее в отдельный метод вытащил (expectedEmptyFileString). О какой именно "строке" речь? Не совсем понял. Рискну предположить, что речь идёт о XML-файле, и что ты считаешь, что в ODS-файле хранится зазипованный XML. Это не совсем так: в ODS несколько зазипованных XML-файлов, причём организованных в директории. Причём структура этих директорий и названия файлов не заданы жестко. Есть один (кажется) файл, в котором указаны имена и адреса остальных файлов, и что какой из остальных файлов значит. Но если я считаю этот файл, начну его парсить, а распарсив- скачаю другие файлы. То тогда я буду писать скорее импортер, чем тесты к экспортеру. Разъяснишь поподробнее? 1 декабря 2014 г., 9:03 пользователь Dennis Schetinin <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
CONTENTS DELETED
The author has deleted this message.
|
Re: TDD и вообще юнит-тесты in the wild
|
|
CONTENTS DELETED
The author has deleted this message.
|
Re: TDD и вообще юнит-тесты in the wild
|
|
In reply to this post by Yuriy Mironenko
У меня только один ответ есть на все прозвучавшие вопросы — и я его уже озвучивал. Попробую еще один вариант. Если мыслить в рамках "как затестить", когда уже есть (в коде или голове) готовое решение и вопрос в том, как к нему написать тест, то чаще всего бывает именно так — тест написать или невозможно, или он получается "уродским". Сама постановка вопроса к этому приводит. Код, который меня "учили" (не очень подходящее слово… скорее "стимулировали") писать редко получается тестируемым. Чтобы код был тестируемым надо приложить определенные усилия. Иногда это не тривиально и даже контр-интуитивно. TDD позволяет на это надеяться, хотя и НЕ это является сутью этой методологии. TDD решает задачу перехода от системы A (в которой отсутствует некая функциональность) к системе B (в которой эта функциональность присутствует). Вся хитрость освоения TDD заключается в выработке навыка постепенно формализовать эту разницу и записывать ее в виде спецификации для последовательности примеров использования этой самой функциональности. И чтобы ответить на поставленный(-ые) вопрос(-ы) в рамках TDD, надо знать не только разрабатываемую функциональность, но и всю (имеющую отношение к этой ф-ти) A. Причем, может так оказаться, что написать направляющий тест для конкретной реализации A будет либо слишком сложно, либо невозможно — особенно, если об этом аспекте никто и не задумывался при создании A. И (по моему опыту) шансы получить такую ситуацию при "диком" проектировании гораздо выше, чем при последовательном TDD. чтобы в справочнике клиентов было место рождения Если не знать, что такое справочник клиентов, ничего сделать не получится. Если предположить, что это нечто простое типа коллекции объектов — не понятно затруднение при написании теста. По остальным вопросам ситуация такая же. Поэтому лучше брать более-менее законченный пример и идти последовательно. (Как мы и пытаемся начать делать в другой ветке.) Очень похоже, что именно это является барьером для тех кто пытается по-быстренькому освоить TDD: на вопрос "как через TDD реализовать то-то?" — ответа нет! Надо идти — шагами, желательно маленькими (но при этом быстрими). Это относится и к реализации системы, и к освоению TDD :) В этом же заключается и проблема "игрушечности" таких примеров: брать полномасштабную проблему слишком тяжело и ничего нового к пониманию, на самом деле, это не добавит. По крайней мере, я именно так "продирался": тренируясь на маленьких примерах, получал опыт; возникали идеи о том, как сделать более крупные вещи и т.д.; потом с трудом "вкурил" моки (как и очень многим, если не большинству, это казалось поначалу тавтологией) — но когда "ухватываешь" смысл, все складывается как мозаика. Как и практически в любом деле, попытка решить слишком сложную задачу ничего кроме разочарования не принесет. Начинать учиться играть в хоккей с вопроса "Ну, как мне чемпионат мира выиграть?" или изучать физику с попытки объяснить природу гравитации едва ли представляется разумным. -- Best regards, Dennis Schetinin 2 декабря 2014 г., 1:18 пользователь Юрий Мироненко <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
In reply to this post by vmusulainen-2
Здесь для самого себя надо отделить что "мы тестируем быстро и модульно” и что "мы тестируем долго и полностью”. Вот с этим я не совсем согласен. Да, здесь нужно тестировать "кооперацию" — точнее, взаимодействие несколько объектов. И это вполне могут быть модульные тесты. На этот случай и придуманы моки. Более того, именно начиная с этого, можно выстроить "архитектуру" (я не просто так беру это слово в кавычки) через TDD. Прямо сейчас не могу как следует заняться этим примером (он выглядит гораздо интереснее, чем казалось сначала). Постараюсь в ближайшее время найти возможность для этого. Было бы замечательно, если бы устройство ODS кто-ниубудь описал точнее. (Я,действительно, думал там надо просто сформировать XML). Или можем взять за основу то, что написано (независимо от правильности) — для исследования TDD это не важно. Но на изучение формата ODS у меня точно не хватит ни времени, ни сил :) -- Best regards, Dennis Schetinin 2 декабря 2014 г., 3:55 пользователь Vladimir Musulainen <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
Re: TDD и вообще юнит-тесты in the wild
|
|
Ну, чтобы было общее понимание: нужно сформировать не одну, а несколько XMLек. По одной на каждый worksheet (этот worksheet по общим идеям будет напоминать HTMLную таблицу), одну на workbook, одну на таблицу стилей и ещё одну - на файл с описанием того, какая из остальных XMLек воркбук, какая - воркщит(ы), какая - таблица стилей и где они все лежат (потому что они не обязаны лежать в корне документа). И всё это зазиповать. Это в простейшем случае. В более сложном там могут быть, например, ещё и картинки. Но мы пока не будем так извращаться. Насколько я понимаю, этого описания, теоретически, должно быть достаточно для того, чтобы начать давать задачи по написанию тестов, которые я могу написать и сам. 2 декабря 2014 г., 11:36 пользователь Dennis Schetinin <[hidden email]> написал:
-- http://groups.google.ru/group/sugr --- Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group". Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email]. Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout. |
«
Return to русский язык (Russian)
|
1 view|%1 views
| Free forum by Nabble | Edit this page |