Как написать модульный тест во время разработки?

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

Но у меня есть вопрос здесь:

Перед тем, как завершить всю систему программного обеспечения, как я должен определить, какие функции мне нужно написать модульное тестирование для? Другими словами, какая лучшая степень детализации для модульного теста?

Что еще хуже, имя или функциональность проверенных функций могут быть изменены во время разработки или после рефакторинга времени, как я должен поддерживать модульный тест?

источник

2015-01-24 xjsXjtu

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

Вместо этого вы должны спросить у [programers.se]. – JJJ

Теоретически все функции, которые участвуют в производственном коде (то есть код, который работает на производственной машине), должны охватываться модульными тестами. Они подпадают под метрику, называемую [Кодовое покрытие] (http://en.wikipedia.org/wiki/Code_coverage). Естественно, лучше. –

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

поэтому, когда вы хотите создать калькулятор вы пишете тест:

int result = new Calculator().add(4,3); 
assertThat(result).isEqual(7);

и теперь вы знаете, что код, который вы должны написать

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

источник

2015-01-25 02:31:12 piotrek

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

Это не похоже на c-код, для которого сложнее сделать TDD –

@ BЈовић, я не сказал, что это сложнее. Я сказал, что самый простой способ начать тестирование - это TDD. и это пример TDD – piotrek

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

источник

2015-01-26 11:14:34 Eugene

нет классов в c –

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

Как определить, какие функции мне нужны для тестирования единицы измерения?

Прост: попробуйте выполнить единое тестирование, что бы вы ни выбрали, и постарайтесь максимально охватить покрытие блоков. Конечно, некоторые вещи не могут быть подвергнуты блочному тестированию (доступ к конкретному HW или DB), и некоторые вещи не должны тестироваться на единицу (функциональность сторонней библиотеки).

Какая наилучшая степень детализации для модульного теста?

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

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

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

источник

2015-01-26 13:36:03

Как написать модульный тест во время разработки?

ответ

Смежные вопросы