Новое имя для юнит-тестов [закрыто]

9

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

Теперь я люблю модульные тесты, так как они позволяют мне писать полезный код, который довольно часто работает с первого раза! (постучать по дереву)

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

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

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

Я взломан или кто-то еще видит этот отказ от тестирования и думают ли они, что это та же самая причина, по которой они не хотят это делать?
Какие причины вы / другие приводите для отказа от тестирования?
Как вы думаете, что их мотивы не в модульном тестировании?

И как новое имя для модульного тестирования, которое может снять некоторые возражения, как насчет jContract? (Немного ориентирован на Java, я знаю :), или Unit Contracts?

Будет
источник
14
Что в имени? то, что мы называем розой под любым другим именем, будет пахнуть сладко; - Шекспир, Ромео и Джульетта, ок.1600
Стивен А. Лоу
8
Я не знаю, если вы взломали. Я никогда не пробовал взломать или быть тобой.
Тим Пост
1
Я думаю, что идеи привязываются к словам в основном из-за связанных с ними идей и установок, а не из слов. Я помню, как узнал, что Общество Спастиков изменило свое название на Scope, потому что это имя было связано с предрассудками. Я помню, потому что это объясняло, почему я слышал, как дети в тот день называли друг друга «простыми». Если вы хотите изменить отношение, сосредоточьтесь на отношении, а не на имени - одержимость именем - это просто потеря времени.
Steve314
2
Дизайн по контракту: en.wikipedia.org/wiki/Design_by_contract Имеет определенную связь, и юнит-тесты не так ли. Если я вижу что-то с Контрактом в названии, это (и интерфейсы) - это то, что мой мозг связывает с этим.
Берин Лорич
@ Steve314 Скопи. Нравится. :) Я думаю, что в этом случае слово «тестирование» уже определено, и поэтому было бы лучше переименовать юнит-тесты в неопределенный термин. Контракт не может быть из-за упомянутого «интерфейса». Как насчет «создавать лучшие программы быстрее» или CBPF.
Уилл

Ответы:

5

Я взломан или кто-то еще видит этот отказ от тестирования и думают ли они, что это та же самая причина, по которой они не хотят это делать?

Слово тестирование в модульном тестировании заставляет людей думать, что это интеграционное тестирование или тестирование пользовательского интерфейса, потому что это единственный вид тестирования, который они когда-либо проводили. Это как положить Java в JavaScript.

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

Какие причины вы / другие приводите для отказа от тестирования?

Зависимости, которые трудно подделать / подделать /

Как вы думаете, что их мотивы не в модульном тестировании?

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

MatthewMartin
источник
Великолепные моменты. Трудно объяснить, почему вы «протестировали» простой метод get, объяснив, почему для стабильности всего остального кода с точки зрения контракта важно, чтобы метод get всегда возвращал то, что, как вы ожидаете, является более простым аргументом
Уилл
3

Концепция смены имени уже была предложена. Это называется поведенческим развитием . Парни, которые придумали это, заметили много таких же аргументов плюс неестественное приспособление для тестирования того, что еще не создано. Вместо этого их концепция состоит в том, чтобы написать исполняемую спецификацию (о чем, собственно, и есть TDD).

Я заметил такой же откат. Я также заметил, что многие люди просто не знают, как писать модульные тесты. Им не хватает дисциплин научного процесса, и они просто используют среду модульного тестирования как способ связать все вместе и запустить отладчик. Короче говоря, они действительно не улучшают использование своего времени. Я не могу сказать вам, сколько модульных тестов я видел, которые были длиной в несколько десятков строк (более 30 строк) и ни одного утверждения assert. Когда я вижу это, я знаю, что пришло время поработать с разработчиком и научить их, что такое утверждение и как писать модульные тесты, которые на самом деле тестируют.

Берин Лорич
источник
2
Исполняемая спецификация, вероятно, предшествует TDD / BDD / Agile / XP. Это может быть так же старо, как CMMI. Когда-то люди думали, что UML - это язык для написания ES.
Rwong
BDD, как и TDD, является подходом к тестированию, а не видом тестирования (функционал v интеграция v блок v принятие). Автор спрашивает конкретно о «лучшем» названии для юнит-тестирования.
Ибакос
0

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

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

Леннарт Регебро
источник
0

Я скажу вам, почему мне не нравится TDD: это не потому, что я не вижу значения в нем, или признаю преимущества набора тестов, который я могу запустить для проверки всего своего кода после каждой модификации.

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

Я проверяю свой код, но, как я всегда делал, это касается всего, а не отдельных частей. Так что, может быть, у меня есть «модульные тесты», но они более грубые.

Это моя причина. Я не вижу необходимости для меня, чтобы сделать это. Код, который я создаю, достаточно хорош, и если это так, почему я должен изменить свои процессы, чтобы исправить то, что не сломано?

gbjbaanb
источник
Вы должны написать очень простой код. Количество достижимых состояний в большинстве современных систем означает, что для проведения сквозного тестирования потребуется время жизни юниверса - для тестирования двух частей, каждый с 4-битным состоянием, требуется 16 тестов для каждого, или 32 тестовых случая в целом; превращение в сквозную систему дает 8 бит состояния или 256 тестовых случаев для охвата всех состояний. Лично я предпочел бы сделать 1/8 работы.
Пит Киркхам,
1
@PeteKirkham, следствие этого заключается в том, что вам нужно написать большое количество модульных тестов, а затем написать интеграционные тесты, чтобы убедиться, что модуль все еще работает друг с другом. Те места, где я работал, которые очень любили модульные тесты, тратили так много времени на написание (и поддержку) их, что они затмевали кодовую базу, и объем работы, которую они выполняли, был крошечным по сравнению с тем, что я выполняю вне этой среды. Ничто не является волшебной пулей, я рекомендую попытаться найти более прагматичный подход, который даст вам возможность протестировать важные моменты, а также что-то создать.
gbjbaanb