Я никогда не любил юнит-тестирование. Я всегда думал, что это увеличило объем работы, которую я должен был сделать.
Оказывается, это верно только с точки зрения фактического количества строк кода, которые вы пишете, и, более того, это полностью компенсируется увеличением количества строк полезного кода, которые вы можете написать за час с помощью тестов и разработки, управляемой тестами.
Теперь я люблю модульные тесты, так как они позволяют мне писать полезный код, который довольно часто работает с первого раза! (постучать по дереву)
Я обнаружил, что люди неохотно проводят юнит-тесты или начинают проект с разработки на основе тестов, если они находятся в строгих временных рамках или в среде, где другие этого не делают, поэтому они этого не делают. Вроде как, культурный отказ даже попробовать.
Я думаю, что одна из самых важных вещей в модульном тестировании - это уверенность, которую он дает вам для проведения рефакторинга. Это также дает новую надежду, что я могу передать свой код кому-то другому для рефакторинга / улучшения, и если мои модульные тесты все еще работают, я могу использовать новую версию библиотеки, которую они модифицировали, почти без страха.
Это последний аспект модульного тестирования, который, я думаю, нуждается в новом имени. Модульное тестирование больше похоже на контракт того, что этот код должен делать сейчас и в будущем.
Когда я слышу слово «тестирование», я вспоминаю о мышах в клетках, на которых было проведено несколько экспериментов, чтобы увидеть эффективность соединения. Это не то, что такое модульное тестирование, мы не пробуем другой код, чтобы увидеть наиболее эффективный подход, мы определяем, какие результаты мы ожидаем с какими входами. В примере с мышами юнит-тесты больше похожи на определения того, как будет работать вселенная, а не на эксперименты, проведенные на мышах.
Я взломан или кто-то еще видит этот отказ от тестирования и думают ли они, что это та же самая причина, по которой они не хотят это делать?
Какие причины вы / другие приводите для отказа от тестирования?
Как вы думаете, что их мотивы не в модульном тестировании?
И как новое имя для модульного тестирования, которое может снять некоторые возражения, как насчет jContract? (Немного ориентирован на Java, я знаю :), или Unit Contracts?
источник
Ответы:
Слово тестирование в модульном тестировании заставляет людей думать, что это интеграционное тестирование или тестирование пользовательского интерфейса, потому что это единственный вид тестирования, который они когда-либо проводили. Это как положить Java в JavaScript.
Когда у чего-то плохое имя, и это влияет на то, что люди думают об этом, это называется ошибкой фрейминга. Ошибки в оформлении имеют тенденцию быть поверхностными - люди умны и могут видеть все виды плохих имен, плохих метафор.
Зависимости, которые трудно подделать / подделать /
Модульное тестирование имеет скромное количество концептов, и нужно выполнить нетривиальный объем работы, прежде чем перестанут писать плохие юнит-тесты и начнут писать хорошие. По мере того, как люди будут лучше объяснять, что такое модульное тестирование, их использование будет увеличиваться. По моему опыту, модульное тестирование оказывает почти магическое влияние на производительность и качество кода. Но это началось не так. Первоначально я использовал модульное тестирование как удобный способ написания интеграционных тестов.
источник
Концепция смены имени уже была предложена. Это называется поведенческим развитием . Парни, которые придумали это, заметили много таких же аргументов плюс неестественное приспособление для тестирования того, что еще не создано. Вместо этого их концепция состоит в том, чтобы написать исполняемую спецификацию (о чем, собственно, и есть TDD).
Я заметил такой же откат. Я также заметил, что многие люди просто не знают, как писать модульные тесты. Им не хватает дисциплин научного процесса, и они просто используют среду модульного тестирования как способ связать все вместе и запустить отладчик. Короче говоря, они действительно не улучшают использование своего времени. Я не могу сказать вам, сколько модульных тестов я видел, которые были длиной в несколько десятков строк (более 30 строк) и ни одного утверждения assert. Когда я вижу это, я знаю, что пришло время поработать с разработчиком и научить их, что такое утверждение и как писать модульные тесты, которые на самом деле тестируют.
источник
Контракты называются «интерфейсами» в большинстве случаев здесь. Наличие модульных тестов само по себе не гарантирует контракты, так как вы также можете изменять тесты, так что вы на самом деле не знаете, что можете использовать новую версию библиотеки только потому, что библиотека протестирована. Вам нужно протестировать код, который тоже использует библиотеку. Это не отличается от любого другого модульного тестирования, поэтому я не понимаю, почему для этого нужно новое имя.
Я думаю, как и вы, что большинство людей не хотят делать тесты, потому что они думают, что это больше работы и бесполезно.
источник
Я скажу вам, почему мне не нравится TDD: это не потому, что я не вижу значения в нем, или признаю преимущества набора тестов, который я могу запустить для проверки всего своего кода после каждой модификации.
Это потому что мне это не нужно. Я довольно старомодный разработчик, когда я был парнем, у нас не было красивых встроенных отладчиков с редактированием и продолжением записи кода, и компиляция могла занимать довольно много времени, поэтому нам нужно было что-то делать правильно, с самого начала. Учитывая такое обучение, я не вижу, чтобы написание множества модульных тестов сделало бы меня более продуктивным или мой код стал бы более безошибочным.
Я проверяю свой код, но, как я всегда делал, это касается всего, а не отдельных частей. Так что, может быть, у меня есть «модульные тесты», но они более грубые.
Это моя причина. Я не вижу необходимости для меня, чтобы сделать это. Код, который я создаю, достаточно хорош, и если это так, почему я должен изменить свои процессы, чтобы исправить то, что не сломано?
источник