тестирование и жизнь

[dz]

Мой экспресс-пост про тестирование вызвал бурление мнений

Comments

[dilesoft]

Прямо как на баше.

define true false; // Счастливой отладки, суки.

[gornal]

q2. А разве не практически любой?

[dz]

посыплются десятки тестов, но ни один не укажет на истинную причину.

[dmarck]

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

Не панацея, да, но экономит время и нервы всем.

Coverity Prevent плюс это, кстати, тоже в ту сторону.

[gornal]

Коммит подлый определится, дальше дело автора его доотлаживать. Но, главное, бомбу под будущее пронести не удастся.

[raydac]

понятно что у функции был тест asserEquals(4,power(2,2)), но это только показывает что компания была создана на базе деревенского дурдома и отсутсорсила примерно аналогичному заказчику для медицинских целей

[rblaze]

q1b: Тест должен был выглядеть так:
testRaiseToPower :: Word -> Small Word -> Property
testRaiseToPower x (Small y) = raiseToPower x y == (ручное возведение в степень через цикл или как угодно еще)

После чего QuickCheck нагенерит сотню разных случайных примеров, обмануть его довольно сложно.

Отдельно сделать тесты с таймингами, если надо чтобы код работал быстрее чем ручное возведение. Если не надо - можно скопировать, всё в порядке.

[alxt]

Про 2*2=4. Понятное дело, что unit-тесты не панацея, и не гарантия.
Это просто дополнительные проценты в вероятности отсутствия ошибок.

А #define False -1 показывает, что в говноязыке (С/С++) ничего не поможет. Жаль, что eiffel практически не взлетел, но та же java не позволяет подобных граблей. Язык должен максимально ограничивать в написании говнокода. И аннотации типов в java 8 тоже не просто придуманы в т.ч. для тестирования. Так что про "какой тест поймает такое"- это тест на неиспользование С/С++ :)

Плюс version control, continuous integration и т.д. и т.п. тоже дают свои процентики- к вопросу в "диффов не было".

[ext_1684112]

>eiffel практически не взлетел

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

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

[alxt]

> У меня есть предположение, почему. Кому-то очень хотелось агрессивно продвигать английский язык в качестве универсального языка для программистов. Естественно, французский эйфель был задвинут.

Чепуха.
1. В то время (86 год) ООП мало кто не понимал. Одно дело, когда язык 100% обратно совместим, что позволяет вставлять в проект куски кода на С++, другое- когда всё по-другому и ломать мозг надо серьёзно.
2. Когда я его изучал (2003 год примерно) и то, не было приличного доступного компилятора. В отличии от того же С++. Это сейчас компилятор подобного уровня сложности может работать в фоне, а тогда он сильно отставал по скорости и оптимальности бинарного кода.
Так что в "борьбе" с С++ eiffel был обречён из-за большого порога вхождения во всех смыслах.

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

Если команда, хотя бы потенциально, многоязычная- это оправдано. Иначе- да, скорее понты руководятла.

[ext_1684112]

В 86 году C++ уже широко использовался разве? Я помню обсуждения на РСДН, 2002 года, что ли, в которых люди из вполне себе многоязычных команд писали, что вот у себя в проекте STL и шаблонов не допускают. 2002, не 86. И чем такой подход отличался от Си с классами?