Какова не должна быть протестированная единица?
sed -n '16224,16482p;16483q' filename > newfileОт sed руководство :
p - Распечатывают пространство шаблона (к стандартному выводу). Эта команда обычно используется только в сочетании с-n параметром командной строки.
n - Если автопечать не отключена, распечатайте пространство шаблона, то, независимо, заменяют пространство шаблона следующей строкой входа. Если там больше не вводится тогда sed, выходы, не обрабатывая больше управляет.
q - Выход
sed, не обрабатывая больше управляет или вход. Обратите внимание, что текущее пространство шаблона печатается, если автопечать не отключена с-n опцией.Адреса в sed сценарии могут быть в любой из следующих форм:
номер , Определяющий номер строки, будет соответствовать только что строка во входе.
диапазон адресов может быть определен путем определения двух адресов, разделенных запятой (). Диапазон адресов соответствует строкам, начинающим с того, где первый адрес соответствует и продолжается до вторых соответствий адреса (включительно).
6 ответов
My general approach is "if this code is not worth testing, why is it worth having in the first place"? If I'm using a language which forces me to have a lot of uselessly repetitive boilerplate, then maybe I don't need to test those parts if the language's compiler can just check them; but I normally use languages where code I write is actually meaningful;-).
Can you given an example of problem that's too hard to unit-test? I've heard this used as an excuse to avoid testing error-recovery and diagnostic code that's only triggered by rare and very unlikely circumstances, but every time this has come up I've argued that, on the contrary, that code is the one most needing unit tests, because it's not going to get exercised in the integration tests and normal use (e.g. at QA stage).
Dependency Injection lets you use a fake or mock object to stand for (whatever "should never cause this error but we're covering for it anyway" -- network, database, power control interface, etc), and your fake or mock easily can and definitely should cause fake errors of all kinds so you can thoroughly check that error-recovery and diagnostic code.
Maybe it depends on what kind of apps you write -- for the last few years I've been mostly in cluster-management software, where everything that can go wrong will, lots of things that can't possibly go wrong will anyway, and uptime and fast recovery are crucial. In that field nobody would ever dare argue against a belt-and-suspenders approach (if they did the reliability engineers would be after them with cudgels;-).
But I've recently switched to Business Intelligence and I've noticed the approach translates well, too: if the numbers my code is producing (maybe to show as a nice graph to business decision makers, etc) are worth producing at all, they'd better be accurate, which means (among other things) that the code producing them needs to be tested just as thoroughly and carefully as that which monitors a network or a power supply system!-)
Это вопрос стоимости и выгоды, чем ближе вы попытаетесь достичь 100%, тем дороже это будет.
Существует также уровень пользовательского интерфейса, если он находится в технологии, которую сложно протестировать, вы можете запрограммировать этот слой так, чтобы он был как можно более тонким, а затем тестировать его только вручную.
В зависимости от вашей ситуации вы можете отказаться от тестирования сквозных слоев и сгенерированного кода.
Обратите внимание, что это не только вопрос покрытия кода, но и того, как вы тестируете, может быть лучше провести много тестов на ограниченной части кода и с меньшим покрытием кода.
Вы не должны писать модульные тесты для чужого кода (например, для используемой вами среды). Вы должны писать тесты только для своего кода. Смоделируйте зависимости от чужого кода, чтобы вам нужно было писать тесты только для своего.
Вам не нужно тестировать языковые конструкции, но помимо этого, действительно нет ничего, что "не должно" проходить модульное тестирование.
Если есть случаи, когда вы ' Если у вас уже есть дизайн и веская причина для его существования, и это не критически важная часть приложения, такая как второстепенная функция пользовательского интерфейса, то можно сделать аргумент, что не обязательно бороться за создание модуля тест на. Но это не обязательно то же самое, что «не следует» проходить модульное тестирование.
В моем текущем проекте я выполняю автоматическое тестирование функций и функциональности системы, но не тестирую unit вообще: Следует ли тестировать внутреннюю реализацию или тестировать только общедоступное поведение?
Некоторые люди говорят так, будто единственной альтернативой модульному тестированию является специальное ручное тестирование; но многие преимущества (например, регрессионное тестирование) проистекают из того, что тестирование автоматизировано , и не обязательно из-за того, что оно находится на уровне единицы .
Автоматические модульные тесты нельзя запускать для графического кода, поскольку компьютер не может решить, действительно ли то, что отображается на экране, правильно или нет! Хотя в этом случае вы, конечно, можете написать ручной модульный тест