Есть ли такая вещь как чрезмерное поблочное тестирование? [закрытый]

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

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

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

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

Методология TDD - приблизительно разработка - наличие комплекта тестов на потом является довольно желанным побочным эффектом. Разработка через тестирование показывает совершенно другой код, чем наличие тестов "просто" машинально.

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

Моя персональная история для сверхспроектированного тестирования является сверхдразнившим тестом, где реализация некоторых классов была более или менее зеркально отражена в, 'ожидают '-вызовы к соответствующим фиктивным объектам. Разговор о сопротивлении для принятия к измененным требованиям...

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

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

при тестировании этого, это правильно читает в каждом значении в файле конфигурации, затем Вы тестируете файл конфигурации, не код.

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

В том, что точка разработчик должна прекратить писать модульным тестам и делать фактическую работу?

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

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

Так, окончательное руководство, на какой тесты записать должен быть Ваш доверительный уровень о производственном коде. Это - то, где молитва Экстремального программирования "тестирует все, что могло возможно повредиться", прибывает из - если что-то могло бы возможно повредиться, нам нужен тест как наша система поддержки, чтобы смочь переместиться быстро в будущее, путем рефакторинга с уверенностью. Если что-то "не могло бы возможно повредиться" (как часто говорится о простых средствах доступа), пишущий, что тесты для него были бы всеми отходами.

, Конечно, Вы время от времени перестали работать в своей оценке. Вы должны будете испытать для нахождения правильного баланса. Самое главное, каждый раз, когда Вы получаете отчет об ошибках против своего кода, необходимо думать о том, какой тест препятствовал бы тому, чтобы эта ошибка вышла в дикую местность, и предотвратит подобные ошибки в будущем. Затем добавьте этот вид теста к Вашему набору тестов для кода, "который мог возможно повредиться".

Конечно, можно сверхпротестировать тот же способ, которым можно сверхспроектировать.

, Поскольку Вы следуете за Разработкой через тестирование, необходимо завоевать доверие о коде и остановке, когда Вы достаточно уверены. Когда в сомнении, добавьте новый тест.

О тривиальных тестах, экстремальное программирование, говорящее об этом," тест все, что могло повредиться ".

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

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

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

РЕДАКТИРОВАНИЕ: кажется, существует некоторый беспорядок относительно того, что я пытаюсь сказать. Я не говорю, что поблочное тестирование и тестирование функции являются тем же самым - они не. На Википедия : "единица является самой маленькой тестируемой частью приложения", и логически такие 'единицы' меньше, чем большинство 'функций'.

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

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

Да, действительно возможно записать чрезмерные суммы модульных тестов. Например,

• методы считывания тестирования и методы set.
• тестирование, что функциональность языка Бэйсик является работами.

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

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

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

С тем сделанным тестом, не необходимо перепроверить, что возможность в течение каждого раза, когда другой класс использует средство, которое Вы уже протестировали. Иначе для каждой функции Вы тестируете, необходимо было бы повторно протестировать каждую функцию операционной системы, на которую она полагалась. Тесты для данной функции только должны протестировать то, в чем код той функции ответственен за разбирание.

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

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

Модульные тесты должны протестировать каждую часть функциональности, пограничных случаев и иногда угловых случаев.

, Если Вы находите, что после тестирования края и угловых случаев, делаете "средние" случаи, затем это, вероятно, чрезмерно.

, Кроме того, в зависимости от Вашей среды, модульные тесты могли бы быть или довольно трудоемкими для записи, или довольно хрупкий.

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

Одна вещь отметить, основанный на некоторых данных ответах, состоит в том, что, если Вы находите, что необходимо записать многочисленные модульные тесты, чтобы сделать то же самое много раз, рассмотрите рефакторинг первопричины рассматриваемого кода.

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

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

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

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

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

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

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

Относительно некоторых Ваших специфических особенностей: Я определенно протестировал бы свой синтаксический анализатор файла конфигурации, чтобы видеть, что он может проанализировать каждое значение каждого ожидаемого типа. (Я склонен полагаться Lua для файлов конфигурации и парсинга, но это все еще оставляет меня с некоторым тестированием, чтобы сделать.), Но я не записал бы модульный тест на каждую запись в файле конфигурации; вместо этого я записал бы табличную среду тестирования, которая опишет каждую возможную запись и была бы генерировать тесты от этого. Я, вероятно, генерировал бы документацию из того же описания. Я мог бы даже генерировать синтаксический анализатор.

, Когда Ваше приложение пишет записи в журнал, Вы поворачиваете в интеграционные тесты. Лучший подход должен был бы иметь отдельный компонент входа как системный журнал. Затем Вы можете единица тестировать регистратор, помещать его на полку и снова использовать его. Или еще лучше, системный журнал повторного использования. Короткий интеграционный тест может затем сказать Вам, взаимодействует ли Ваше приложение правильно с системным журналом.

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

я надеюсь, что часть этого помогает.