В примерах книги Кента Бекка про TDD он пишет простые юнит-тесты, где обычно корректность работы к.-то функциональности проверяется на каком-то одном экземпляре входных данных. А вообще, в тестах своих вы как поступаете?
Я вот до сих пор, вместо того, чтобы писать:

assertTrue(Number.isNatural(2));

писал что-то вроде:

for (int i = 1; i <= MAX; ++i) {
    assertTrue(Number.isNatural(i));
}

Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

Здравствуйте, kurel, Вы писали:

K>писал что-то вроде:
K>

K>for (int i = 1; i <= MAX; ++i) {
K>    assertTrue(Number.isNatural(i));
K>}
K>

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

Как минимум, усложняется локализация ошибки (точнее, значения данных) в случае непрохождения теста. В таких случаях я добавлял (пользуюсь NUnit) в вызов Assert текущее значение тестовых данных.

Здравствуйте, kurel, Вы писали:

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.


Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма. Ну и на assertFalse(Number.isNatural(1.5)) тоже не помешает

Как уже объяснил коллега andrey82, вариант с циклом плох.
Для подобных тестов есть специальные инструменты — теории в JUnit/NUnit, а в TestNG похожий синтаксис имеют параметризованные тесты.

Здравствуйте, kurel, Вы писали:

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

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

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

Здравствуйте, Sshur, Вы писали:

S>Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма. Ну и на assertFalse(Number.isNatural(1.5)) тоже не помешает

Блин, а я дурак до сих пор тестировал свой код, как черный ящик. Только вот посмотрев, какие тесты пишет Кент Бек к своему коду, начал догадываться, что что-то не так.

Здравствуйте, kurel, Вы писали:

K>Здравствуйте, Sshur, Вы писали:

S>>Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма. Ну и на assertFalse(Number.isNatural(1.5)) тоже не помешает

K>Блин, а я дурак до сих пор тестировал свой код, как черный ящик. Только вот посмотрев, какие тесты пишет Кент Бек к своему коду, начал догадываться, что что-то не так.

Это ирония была? Каждый волен писать как он хочет

Как по мне, так юнит тесты подразумевают проверку срабатывания заложенных сценариев. Если неизвестно, какие сценарии предполагаются, то это уже не юнит тесты

Здравствуйте, Sshur, Вы писали:

S>Это ирония была?

нет

Здравствуйте, kurel, Вы писали:

K>Здравствуйте, Sshur, Вы писали:

S>>Это ирония была?

K>нет

ну и хорошо

Еще вопрос. Немного связанный с предыдущим.
Какой из тестов "лучше"?

tree = BinaryTree()
tree.add(5)
assertEquals(tree.getRoot(), Node(5))
assertIsNone(tree.getRoot().leftChild())
assertIsNone(tree.getRoot().rightChild())

или

tree = BinaryTree()
for n in range(0, 2):
    tree.add(5)
    assertEquals(tree.getRoot(), Node(5))
    assertIsNone(tree.getRoot().leftChild())
    assertIsNone(tree.getRoot().rightChild())

Откуда возник второй такой дебильный тест?
Там проверяется, что происходит, если в дерево с одним узлом добавить значение, равное значению в единственном узле (это проверяется во втором цикле).

Или вы бы написали только первый тест?

Здравствуйте, kurel, Вы писали:


K>Откуда возник второй такой дебильный тест?
K>Там проверяется, что происходит, если в дерево с одним узлом добавить значение, равное значению в единственном узле (это проверяется во втором цикле).

K>Или вы бы написали только первый тест?

Если подразумевается, что добавление второй такой же ноды должно игнорироваться, то второй шаг цикла это отдельный сценарий и его тоже надо тестировать

Здравствуйте, Sshur, Вы писали:


S>Если подразумевается, что добавление второй такой же ноды должно игнорироваться, то второй шаг цикла это отдельный сценарий и его тоже надо тестировать

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

Здравствуйте, kurel, Вы писали:

K>Или вы бы написали только первый тест?
Тесты разное проверяют. Кто из них лучше -- хз.
Добавь коментарии -- сразу же станет понятнее.

K>Откуда возник второй такой дебильный тест?
K>Там проверяется, что происходит, если в дерево с одним узлом добавить значение, равное значению в единственном узле (это проверяется во втором цикле).
Первый тест это не проверяет. Если его изменить, чтобы проверял, то он будет лучше. В данном случае, любой тест без цикла лучше теста с циклом.

СУВ, Aikin

Здравствуйте, Sshur, Вы писали:

S>Если вы тестируете не черный ящик (а юнит тесты обычно к своему коду пишут, то есть к белому ну или в крайнем случае серому ящику), то достаточно проверить правильное срабатывание всех ветвей алгоритма.

т.е. для рефакторинга такие тесты не помогают?
немного поменял код, и тесты уже не полные?

Здравствуйте, Abyx, Вы писали:


A>т.е. для рефакторинга такие тесты не помогают?
A>немного поменял код, и тесты уже не полные?

Почему? рефакторинг без добавление функционала же делается. Все тесты которые ходили раньше должны ходить. Если что-то пишется новое, то сначала тест, потом код. Это если по TDD.

Здравствуйте, Sshur, Вы писали:

A>>т.е. для рефакторинга такие тесты не помогают?
A>>немного поменял код, и тесты уже не полные?

S>Почему? рефакторинг без добавление функционала же делается. Все тесты которые ходили раньше должны ходить. Если что-то пишется новое, то сначала тест, потом код. Это если по TDD.

я и не говорил про функционал. добавление/удаление ветвей не обязательно меняет функционал

Здравствуйте, Abyx, Вы писали:

A>Здравствуйте, Sshur, Вы писали:

A>>>т.е. для рефакторинга такие тесты не помогают?
A>>>немного поменял код, и тесты уже не полные?

S>>Почему? рефакторинг без добавление функционала же делается. Все тесты которые ходили раньше должны ходить. Если что-то пишется новое, то сначала тест, потом код. Это если по TDD.

A>я и не говорил про функционал. добавление/удаление ветвей не обязательно меняет функционал

Тогда все старые тесты должны ходить, естественно.

Здравствуйте, kurel, Вы писали:

K>Но если чуть подумать, вариант с циклом особых преимуществ не дает. Только — 3 строчки вместо 1 и увеличение времени тестирования.

Для специальных случаев (0, 1, 2) делаются отдельные тесты.
Остальные случаи проверяются циклом еще в одном тесте.

B>Остальные случаи проверяются циклом еще в одном тесте.

За такое надо бить по рукам и заставлять читать книжки про юнит-тесты в частности и теории тестирования вообще.

Здравствуйте, abibok, Вы писали:

B>>Остальные случаи проверяются циклом еще в одном тесте.
A>За такое надо бить по рукам и заставлять читать книжки про юнит-тесты в частности и теории тестирования вообще.

Окей. Как вы тогда напишете тесты для генератора простых чисел?