TDD и вообще юнит-тесты in the wild

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
Я уже поднимал этот вопрос раньше, но ясность у меня так и не появилась.
Вопрос вот какой: как использовать юнит-тестирование, и тем более 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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

vmusulainen-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
Ну вот смотри: сейчас там реально генерируется 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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Alex Kogan
Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Dennis Schetinin
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]> написал:
Ну вот смотри: сейчас там реально генерируется 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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
In reply to this post by Alex Kogan
Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
Но идея об использовании "XML-читалки" в любом случае полезная, спасибо.

26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал:
Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Dennis Schetinin
Это будут именно юнит-тесты.


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 12:54 пользователь Юрий Мироненко <[hidden email]> написал:
Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
Но идея об использовании "XML-читалки" в любом случае полезная, спасибо.

26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал:

Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
Денис, это был ответ на письмо Когана.
Ответ тебе ещё надо сочинить :)

28 ноября 2014 г., 12:15 пользователь Dennis Schetinin <[hidden email]> написал:
Это будут именно юнит-тесты.


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 12:54 пользователь Юрий Мироненко <[hidden email]> написал:

Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
Но идея об использовании "XML-читалки" в любом случае полезная, спасибо.

26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал:

Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Dennis Schetinin
:) Пардон


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 13:26 пользователь Юрий Мироненко <[hidden email]> написал:
Денис, это был ответ на письмо Когана.
Ответ тебе ещё надо сочинить :)

28 ноября 2014 г., 12:15 пользователь Dennis Schetinin <[hidden email]> написал:

Это будут именно юнит-тесты.


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 12:54 пользователь Юрий Мироненко <[hidden email]> написал:

Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
Но идея об использовании "XML-читалки" в любом случае полезная, спасибо.

26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал:

Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Nikolay Kleptsov
У TDD есть один "довесок" напрямую не относящийся к нему. TDD содержит тесты, в которых используются готовые решения (примеры). Например, осваивал MongoTalk именно по тестам.

28 ноября 2014 г., 16:23 пользователь Dennis Schetinin <[hidden email]> написал:
:) Пардон


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 13:26 пользователь Юрий Мироненко <[hidden email]> написал:

Денис, это был ответ на письмо Когана.
Ответ тебе ещё надо сочинить :)

28 ноября 2014 г., 12:15 пользователь Dennis Schetinin <[hidden email]> написал:

Это будут именно юнит-тесты.


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 12:54 пользователь Юрий Мироненко <[hidden email]> написал:

Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
Но идея об использовании "XML-читалки" в любом случае полезная, спасибо.

26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал:

Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.

--
--
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.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
Это да, тесты - весомый довесок к "самокомментирующемуся коду".

28 ноября 2014 г., 14:03 пользователь Nikolay Kleptsov <[hidden email]> написал:
У TDD есть один "довесок" напрямую не относящийся к нему. TDD содержит тесты, в которых используются готовые решения (примеры). Например, осваивал MongoTalk именно по тестам.

28 ноября 2014 г., 16:23 пользователь Dennis Schetinin <[hidden email]> написал:

:) Пардон


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 13:26 пользователь Юрий Мироненко <[hidden email]> написал:

Денис, это был ответ на письмо Когана.
Ответ тебе ещё надо сочинить :)

28 ноября 2014 г., 12:15 пользователь Dennis Schetinin <[hidden email]> написал:

Это будут именно юнит-тесты.


--

Best regards,


Dennis Schetinin


28 ноября 2014 г., 12:54 пользователь Юрий Мироненко <[hidden email]> написал:

Судя по описанию, в любом случае, это будут приёмочные, а не юнит-тесты.
Но идея об использовании "XML-читалки" в любом случае полезная, спасибо.

26 ноября 2014 г., 22:28 пользователь Alexander Kogan <[hidden email]> написал:

Ну надо полагать, что некие известные тебе стандартные входные данные
будут всегда производить стандарную форму 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.

--
--
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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
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]> написал:
Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Поэтому постараюсь быть краток. (Перечитав то, что получилось, добавлю: насколько смогу:)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

За первый вариант мне сказать нечего. Если же мы хотим разрабатывать (именно TDD), то надо решить, с какого момента мы хотим TDD. "Классический" TDD как его описал Кент Бек предполагает некую стадию предварительного проектирования вне рамок TDD. Это примерно то, что предложил Владимир: мы уже где-то как-то придумали какие должны быть объекты, какая к ним приписана функциональность и используем TDD чтобы эту функциональность уточнить и зафиксировать. Не могу сказать, что это не работает — очень даже хорошо работает, но именно в тех рамках, в которых применяется. То есть, если впоследствии оказывается, что предварительный дизайн был не слишком удачным, то придется переделывать и переделывать все — не только основной код, но и тесты. У меня в реальной жизни часто так и получается… слишком часто. Поэтому я стараюсь придерживаться "чистого" TDD, где стадия проектирования не выносится "за скобки". Для меня это работает гораздо лучше — именно в плане дизайна. Но и дизайн получается несколько… специфический… В общем, для тех, кто привык руководствоваться априорными правилами хорошего дизайна, результат выглядит "не очень" (обычно речь идет об избыточной сложности)… Но работает! И сложность оказывается либо не настолько уж избыточной, либо (даже чаще) очень уместной. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени.

И по поводу ожиданий… Здесь, похоже, как раз сказывается отношение к TDD как к способу тестирования. Да, Excel сможет "скушать" разные варианты файлов, но ваш конвертер для конкретного входа будет выдавать какой-то один вариант (если вы не хотите использовать генератор случайных чисел). И вам нужно не описать все правильные варианты, а просто реализовать какой-то один из них. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. На всякий случай уточню: это если "по классике" — с середины начинать :)


--

Best regards,


Dennis Schetinin


26 ноября 2014 г., 18:13 пользователь Юрий Мироненко <[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.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Dennis Schetinin

>> Первое, и самое важное: "тестировать"/"покрывать тестами" и 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]> написал:
Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо.

Вообще, я всегда не прочь прочитать нечто длинное и якобы занудливое, если там подробно раскрывается тема. Я люблю читать, разбираться и разгребать. Долой клиповое сознание! :)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи.
 
Поправь меня, если я ошибаюсь, но ведь в итоге мы приходим к коду, покрытому тестами, в котором тесты играют ту же роль, что юнит-тесты при обычном подходе? То есть, помогают контролировать целостность реализации при последующих модификациях.

Или такие тесты потом нужно ещё писать отдельно?

 
Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

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

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


Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать.

Ну смотри. Допустим, я "специфицировал вплоть до символа", что параметры какого-то тега должны идти в таком-то порядке. А XML-фреймворк решил, что он выдаст мне параметры тега в алфавитном порядке. Меня это устроит, а написанные тесты - будут ругаться.


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

Интерес - и крайне сильный - есть. Недаром же я периодически поднимаю эту тему.

Предлагаю сделать так:

Я начал делать XLSX-экспортёр. За ODS-экспортёр я ещё даже не брался.

Поскольку эти задачи очень и очень похожи друг на друга, имеет смысл XLSX-экспортёр продолжать делать "по старинке", а ODS-экспортёр начать делать с помощью TDD. Тогда будет наглядно видна разница между подходами.

Если такой план тебе нравится - с чего начать?

27 ноября 2014 г., 8:37 пользователь Dennis Schetinin <[hidden email]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Поэтому постараюсь быть краток. (Перечитав то, что получилось, добавлю: насколько смогу:)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

За первый вариант мне сказать нечего. Если же мы хотим разрабатывать (именно TDD), то надо решить, с какого момента мы хотим TDD. "Классический" TDD как его описал Кент Бек предполагает некую стадию предварительного проектирования вне рамок TDD. Это примерно то, что предложил Владимир: мы уже где-то как-то придумали какие должны быть объекты, какая к ним приписана функциональность и используем TDD чтобы эту функциональность уточнить и зафиксировать. Не могу сказать, что это не работает — очень даже хорошо работает, но именно в тех рамках, в которых применяется. То есть, если впоследствии оказывается, что предварительный дизайн был не слишком удачным, то придется переделывать и переделывать все — не только основной код, но и тесты. У меня в реальной жизни часто так и получается… слишком часто. Поэтому я стараюсь придерживаться "чистого" TDD, где стадия проектирования не выносится "за скобки". Для меня это работает гораздо лучше — именно в плане дизайна. Но и дизайн получается несколько… специфический… В общем, для тех, кто привык руководствоваться априорными правилами хорошего дизайна, результат выглядит "не очень" (обычно речь идет об избыточной сложности)… Но работает! И сложность оказывается либо не настолько уж избыточной, либо (даже чаще) очень уместной. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени.

И по поводу ожиданий… Здесь, похоже, как раз сказывается отношение к TDD как к способу тестирования. Да, Excel сможет "скушать" разные варианты файлов, но ваш конвертер для конкретного входа будет выдавать какой-то один вариант (если вы не хотите использовать генератор случайных чисел). И вам нужно не описать все правильные варианты, а просто реализовать какой-то один из них. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. На всякий случай уточню: это если "по классике" — с середины начинать :)


--

Best regards,


Dennis Schetinin


26 ноября 2014 г., 18:13 пользователь Юрий Мироненко <[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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
Книжка Бека про 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]> написал:

>> Первое, и самое важное: "тестировать"/"покрывать тестами" и 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]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо.

Вообще, я всегда не прочь прочитать нечто длинное и якобы занудливое, если там подробно раскрывается тема. Я люблю читать, разбираться и разгребать. Долой клиповое сознание! :)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи.
 
Поправь меня, если я ошибаюсь, но ведь в итоге мы приходим к коду, покрытому тестами, в котором тесты играют ту же роль, что юнит-тесты при обычном подходе? То есть, помогают контролировать целостность реализации при последующих модификациях.

Или такие тесты потом нужно ещё писать отдельно?

 
Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

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

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


Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать.

Ну смотри. Допустим, я "специфицировал вплоть до символа", что параметры какого-то тега должны идти в таком-то порядке. А XML-фреймворк решил, что он выдаст мне параметры тега в алфавитном порядке. Меня это устроит, а написанные тесты - будут ругаться.


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

Интерес - и крайне сильный - есть. Недаром же я периодически поднимаю эту тему.

Предлагаю сделать так:

Я начал делать XLSX-экспортёр. За ODS-экспортёр я ещё даже не брался.

Поскольку эти задачи очень и очень похожи друг на друга, имеет смысл XLSX-экспортёр продолжать делать "по старинке", а ODS-экспортёр начать делать с помощью TDD. Тогда будет наглядно видна разница между подходами.

Если такой план тебе нравится - с чего начать?

27 ноября 2014 г., 8:37 пользователь Dennis Schetinin <[hidden email]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Поэтому постараюсь быть краток. (Перечитав то, что получилось, добавлю: насколько смогу:)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

За первый вариант мне сказать нечего. Если же мы хотим разрабатывать (именно TDD), то надо решить, с какого момента мы хотим TDD. "Классический" TDD как его описал Кент Бек предполагает некую стадию предварительного проектирования вне рамок TDD. Это примерно то, что предложил Владимир: мы уже где-то как-то придумали какие должны быть объекты, какая к ним приписана функциональность и используем TDD чтобы эту функциональность уточнить и зафиксировать. Не могу сказать, что это не работает — очень даже хорошо работает, но именно в тех рамках, в которых применяется. То есть, если впоследствии оказывается, что предварительный дизайн был не слишком удачным, то придется переделывать и переделывать все — не только основной код, но и тесты. У меня в реальной жизни часто так и получается… слишком часто. Поэтому я стараюсь придерживаться "чистого" TDD, где стадия проектирования не выносится "за скобки". Для меня это работает гораздо лучше — именно в плане дизайна. Но и дизайн получается несколько… специфический… В общем, для тех, кто привык руководствоваться априорными правилами хорошего дизайна, результат выглядит "не очень" (обычно речь идет об избыточной сложности)… Но работает! И сложность оказывается либо не настолько уж избыточной, либо (даже чаще) очень уместной. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени.

И по поводу ожиданий… Здесь, похоже, как раз сказывается отношение к TDD как к способу тестирования. Да, Excel сможет "скушать" разные варианты файлов, но ваш конвертер для конкретного входа будет выдавать какой-то один вариант (если вы не хотите использовать генератор случайных чисел). И вам нужно не описать все правильные варианты, а просто реализовать какой-то один из них. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. На всякий случай уточню: это если "по классике" — с середины начинать :)


--

Best regards,


Dennis Schetinin


26 ноября 2014 г., 18:13 пользователь Юрий Мироненко <[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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
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]> написал:

>> Первое, и самое важное: "тестировать"/"покрывать тестами" и 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]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо.

Вообще, я всегда не прочь прочитать нечто длинное и якобы занудливое, если там подробно раскрывается тема. Я люблю читать, разбираться и разгребать. Долой клиповое сознание! :)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи.
 
Поправь меня, если я ошибаюсь, но ведь в итоге мы приходим к коду, покрытому тестами, в котором тесты играют ту же роль, что юнит-тесты при обычном подходе? То есть, помогают контролировать целостность реализации при последующих модификациях.

Или такие тесты потом нужно ещё писать отдельно?

 
Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

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

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


Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать.

Ну смотри. Допустим, я "специфицировал вплоть до символа", что параметры какого-то тега должны идти в таком-то порядке. А XML-фреймворк решил, что он выдаст мне параметры тега в алфавитном порядке. Меня это устроит, а написанные тесты - будут ругаться.


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

Интерес - и крайне сильный - есть. Недаром же я периодически поднимаю эту тему.

Предлагаю сделать так:

Я начал делать XLSX-экспортёр. За ODS-экспортёр я ещё даже не брался.

Поскольку эти задачи очень и очень похожи друг на друга, имеет смысл XLSX-экспортёр продолжать делать "по старинке", а ODS-экспортёр начать делать с помощью TDD. Тогда будет наглядно видна разница между подходами.

Если такой план тебе нравится - с чего начать?

27 ноября 2014 г., 8:37 пользователь Dennis Schetinin <[hidden email]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Поэтому постараюсь быть краток. (Перечитав то, что получилось, добавлю: насколько смогу:)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

За первый вариант мне сказать нечего. Если же мы хотим разрабатывать (именно TDD), то надо решить, с какого момента мы хотим TDD. "Классический" TDD как его описал Кент Бек предполагает некую стадию предварительного проектирования вне рамок TDD. Это примерно то, что предложил Владимир: мы уже где-то как-то придумали какие должны быть объекты, какая к ним приписана функциональность и используем TDD чтобы эту функциональность уточнить и зафиксировать. Не могу сказать, что это не работает — очень даже хорошо работает, но именно в тех рамках, в которых применяется. То есть, если впоследствии оказывается, что предварительный дизайн был не слишком удачным, то придется переделывать и переделывать все — не только основной код, но и тесты. У меня в реальной жизни часто так и получается… слишком часто. Поэтому я стараюсь придерживаться "чистого" TDD, где стадия проектирования не выносится "за скобки". Для меня это работает гораздо лучше — именно в плане дизайна. Но и дизайн получается несколько… специфический… В общем, для тех, кто привык руководствоваться априорными правилами хорошего дизайна, результат выглядит "не очень" (обычно речь идет об избыточной сложности)… Но работает! И сложность оказывается либо не настолько уж избыточной, либо (даже чаще) очень уместной. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени.

И по поводу ожиданий… Здесь, похоже, как раз сказывается отношение к TDD как к способу тестирования. Да, Excel сможет "скушать" разные варианты файлов, но ваш конвертер для конкретного входа будет выдавать какой-то один вариант (если вы не хотите использовать генератор случайных чисел). И вам нужно не описать все правильные варианты, а просто реализовать какой-то один из них. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. На всякий случай уточню: это если "по классике" — с середины начинать :)


--

Best regards,


Dennis Schetinin


26 ноября 2014 г., 18:13 пользователь Юрий Мироненко <[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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

vmusulainen-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

vmusulainen-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Dennis Schetinin
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]> написал:
Книжка Бека про 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]> написал:


>> Первое, и самое важное: "тестировать"/"покрывать тестами" и 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]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо.

Вообще, я всегда не прочь прочитать нечто длинное и якобы занудливое, если там подробно раскрывается тема. Я люблю читать, разбираться и разгребать. Долой клиповое сознание! :)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи.
 
Поправь меня, если я ошибаюсь, но ведь в итоге мы приходим к коду, покрытому тестами, в котором тесты играют ту же роль, что юнит-тесты при обычном подходе? То есть, помогают контролировать целостность реализации при последующих модификациях.

Или такие тесты потом нужно ещё писать отдельно?

 
Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

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

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


Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать.

Ну смотри. Допустим, я "специфицировал вплоть до символа", что параметры какого-то тега должны идти в таком-то порядке. А XML-фреймворк решил, что он выдаст мне параметры тега в алфавитном порядке. Меня это устроит, а написанные тесты - будут ругаться.


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

Интерес - и крайне сильный - есть. Недаром же я периодически поднимаю эту тему.

Предлагаю сделать так:

Я начал делать XLSX-экспортёр. За ODS-экспортёр я ещё даже не брался.

Поскольку эти задачи очень и очень похожи друг на друга, имеет смысл XLSX-экспортёр продолжать делать "по старинке", а ODS-экспортёр начать делать с помощью TDD. Тогда будет наглядно видна разница между подходами.

Если такой план тебе нравится - с чего начать?

27 ноября 2014 г., 8:37 пользователь Dennis Schetinin <[hidden email]> написал:

Еще вчера начал писать длинное письмо и даже с какими-то первыми шагами, но получилось очень долго и занудливо. Поэтому постараюсь быть краток. (Перечитав то, что получилось, добавлю: насколько смогу:)

Первое, и самое важное: "тестировать"/"покрывать тестами" и TDD — совершенно разные вещи. Соответственно, надо понять, что мы хотим: тестировать или разрабатывать. 

За первый вариант мне сказать нечего. Если же мы хотим разрабатывать (именно TDD), то надо решить, с какого момента мы хотим TDD. "Классический" TDD как его описал Кент Бек предполагает некую стадию предварительного проектирования вне рамок TDD. Это примерно то, что предложил Владимир: мы уже где-то как-то придумали какие должны быть объекты, какая к ним приписана функциональность и используем TDD чтобы эту функциональность уточнить и зафиксировать. Не могу сказать, что это не работает — очень даже хорошо работает, но именно в тех рамках, в которых применяется. То есть, если впоследствии оказывается, что предварительный дизайн был не слишком удачным, то придется переделывать и переделывать все — не только основной код, но и тесты. У меня в реальной жизни часто так и получается… слишком часто. Поэтому я стараюсь придерживаться "чистого" TDD, где стадия проектирования не выносится "за скобки". Для меня это работает гораздо лучше — именно в плане дизайна. Но и дизайн получается несколько… специфический… В общем, для тех, кто привык руководствоваться априорными правилами хорошего дизайна, результат выглядит "не очень" (обычно речь идет об избыточной сложности)… Но работает! И сложность оказывается либо не настолько уж избыточной, либо (даже чаще) очень уместной. В общем, если есть интерес, можем попробовать данную задачу с этой точки зрения решить. Мне самому интересно, получится что-то вменяемое или нет. Но это будет не быстро, учитывая необходимость объясняться и наличие свободного времени.

И по поводу ожиданий… Здесь, похоже, как раз сказывается отношение к TDD как к способу тестирования. Да, Excel сможет "скушать" разные варианты файлов, но ваш конвертер для конкретного входа будет выдавать какой-то один вариант (если вы не хотите использовать генератор случайных чисел). И вам нужно не описать все правильные варианты, а просто реализовать какой-то один из них. Поэтому для начала надо взять какой-то один случай ("отщипнуть" от задачи маленький кусочек), специфицировать (вплоть до символа)— именно в первую очередь! — что ваш конвертер должен выдать, записать это в виде теста и реализовать. На всякий случай уточню: это если "по классике" — с середины начинать :)


--

Best regards,


Dennis Schetinin


26 ноября 2014 г., 18:13 пользователь Юрий Мироненко <[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.

--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Dennis Schetinin
In reply to this post by vmusulainen-2
Здесь для самого себя надо отделить что "мы тестируем быстро и модульно” и что "мы тестируем долго и полностью”.
Я бы для быстрых тестов не стал бы создавать workbook с worksheet-ами, потому как тестирование даже экспорта пустого документа - это значит тестировать работу в кооперации нескольких классов. Штук пяти не меньше.
Это не модульные тесты. 

Вот с этим я не совсем согласен. Да, здесь нужно тестировать "кооперацию" — точнее, взаимодействие несколько объектов. И это вполне могут быть модульные тесты. На этот случай и придуманы моки. Более того, именно начиная с этого, можно выстроить "архитектуру" (я не просто так беру это слово в кавычки) через TDD.

Прямо сейчас не могу как следует заняться этим примером (он выглядит гораздо интереснее, чем казалось сначала). Постараюсь в ближайшее время найти возможность для этого. Было бы замечательно, если бы устройство ODS кто-ниубудь описал точнее. (Я,действительно, думал там надо просто сформировать XML). Или можем взять за основу то, что написано (независимо от правильности) — для исследования TDD это не важно. Но на изучение формата ODS у меня точно не хватит ни времени, ни сил :)


--

Best regards,


Dennis Schetinin


2 декабря 2014 г., 3:55 пользователь Vladimir Musulainen <[hidden email]> написал:
Причём структура этих директорий и названия файлов не заданы жестко. Есть один (кажется) файл,  в котором указаны имена и адреса остальных файлов, и что какой из остальных файлов значит. Но если я считаю этот файл, начну его парсить, а распарсив- скачаю другие файлы. То тогда я буду писать скорее импортер, чем тесты к экспортеру.


Здесь для самого себя надо отделить что "мы тестируем быстро и модульно” и что "мы тестируем долго и полностью”.

Я бы для быстрых тестов не стал бы создавать workbook с worksheet-ами, потому как тестирование даже экспорта пустого документа - это значит тестировать работу в кооперации нескольких классов. Штук пяти не меньше.
Это не модульные тесты. 

Я приведу процесс создания xlsx (по памяти, могу соврать)
1. Создание xml c данными
2. Создание файлов связей
3. Упаковка всего в архив

Вряд ли этим всем занимается один класс.

Например, архивирование просится в отдельный класс. На этот класс и пишутся тесты. На входе пачка файлов (или директория) - на выходе архив с заданным именем.
Создание XML тоже отдельная задача.
Пытаться тестировать сразу все - распространенная ошибка. Модульное тестирование проверяет работу маленьких кирпичиков. Приемочное тестирование уже работе механизма в целом или его частей, если механизм достаточно велик. А вот в приемных тестах выбирать разработчику будут ли он это автоматизировать и проводить тесты вручную. Если будет автоматизировать - не обойтись без соответствующего окружения для чтения xlsx. Можно и не парить  xlsx, а открывать через COM  файл EXCEL и запрашивать значения ячеек сверяя с эталонным. Работа с COM медленная и запускать такие тесты накладно каждый десять минут. Поэтому их можно отделить в пачку тестов которые запускается перед мержем бренча разработки в основной бранч (master).

Стоит ли тестировать asset. Не знаю, когда-то я тестировал из любви к искусству. Теперь нет. Тесты идут только на более сложное поведение.

В целом скажу, что правильный подход к тестированию это такое же искусство, как и создавать красивые объектные структуры. Единых лекал нет и в каждом проекте все достаточно индивидуально




--
--
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.
Reply | Threaded
Open this post in threaded view
|

Re: TDD и вообще юнит-тесты in the wild

Yuriy Mironenko
Ну, чтобы было общее понимание: нужно сформировать не одну, а несколько XMLек.

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

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

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

2 декабря 2014 г., 11:36 пользователь Dennis Schetinin <[hidden email]> написал:
Здесь для самого себя надо отделить что "мы тестируем быстро и модульно” и что "мы тестируем долго и полностью”.
Я бы для быстрых тестов не стал бы создавать workbook с worksheet-ами, потому как тестирование даже экспорта пустого документа - это значит тестировать работу в кооперации нескольких классов. Штук пяти не меньше.
Это не модульные тесты. 

Вот с этим я не совсем согласен. Да, здесь нужно тестировать "кооперацию" — точнее, взаимодействие несколько объектов. И это вполне могут быть модульные тесты. На этот случай и придуманы моки. Более того, именно начиная с этого, можно выстроить "архитектуру" (я не просто так беру это слово в кавычки) через TDD.

Прямо сейчас не могу как следует заняться этим примером (он выглядит гораздо интереснее, чем казалось сначала). Постараюсь в ближайшее время найти возможность для этого. Было бы замечательно, если бы устройство ODS кто-ниубудь описал точнее. (Я,действительно, думал там надо просто сформировать XML). Или можем взять за основу то, что написано (независимо от правильности) — для исследования TDD это не важно. Но на изучение формата ODS у меня точно не хватит ни времени, ни сил :)


--

Best regards,


Dennis Schetinin


2 декабря 2014 г., 3:55 пользователь Vladimir Musulainen <[hidden email]> написал:

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


Здесь для самого себя надо отделить что "мы тестируем быстро и модульно” и что "мы тестируем долго и полностью”.

Я бы для быстрых тестов не стал бы создавать workbook с worksheet-ами, потому как тестирование даже экспорта пустого документа - это значит тестировать работу в кооперации нескольких классов. Штук пяти не меньше.
Это не модульные тесты. 

Я приведу процесс создания xlsx (по памяти, могу соврать)
1. Создание xml c данными
2. Создание файлов связей
3. Упаковка всего в архив

Вряд ли этим всем занимается один класс.

Например, архивирование просится в отдельный класс. На этот класс и пишутся тесты. На входе пачка файлов (или директория) - на выходе архив с заданным именем.
Создание XML тоже отдельная задача.
Пытаться тестировать сразу все - распространенная ошибка. Модульное тестирование проверяет работу маленьких кирпичиков. Приемочное тестирование уже работе механизма в целом или его частей, если механизм достаточно велик. А вот в приемных тестах выбирать разработчику будут ли он это автоматизировать и проводить тесты вручную. Если будет автоматизировать - не обойтись без соответствующего окружения для чтения xlsx. Можно и не парить  xlsx, а открывать через COM  файл EXCEL и запрашивать значения ячеек сверяя с эталонным. Работа с COM медленная и запускать такие тесты накладно каждый десять минут. Поэтому их можно отделить в пачку тестов которые запускается перед мержем бренча разработки в основной бранч (master).

Стоит ли тестировать asset. Не знаю, когда-то я тестировал из любви к искусству. Теперь нет. Тесты идут только на более сложное поведение.

В целом скажу, что правильный подход к тестированию это такое же искусство, как и создавать красивые объектные структуры. Единых лекал нет и в каждом проекте все достаточно индивидуально




--
--
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.
1234