2015-04-28 2 views
0

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

Только представьте у нас есть тестовый пример, как показано ниже над кучей наших функций:

Assert.IsTrue(divideNumbers(4,3) == 1); 
Assert.IsTrue(divideNumbers(4,2) == 2); 
Assert.AreEqual(divideNumbers(8, 4), 2); 
Assert.That(divide(10,2), Eq(5)) 

Так, при написании тестового примера, как правило, мы пытаемся утверждать правдивость кучу очень простой такие вопросы, как, правда, два уравнения? Является ли результат этой функции равным желаемому результату? Они равны? Это не так? Является ли объект экземпляром определенного класса ?, .......

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

Итак, почему действительно писать тестовые примеры? Почему мы действительно нуждаемся в них и как они могут помочь нам повысить качество продукции и уменьшить потенциальные ошибки?

+2

Если ваши тестовые примеры не полезны, напишите лучшие тесты! –

+0

Вы спрашиваете, зачем писать модульные тесты, а не тесты интеграции или зачем вообще писать тесты? –

+0

Как? Что такое хороший тест? –

ответ

0

Причиной написания модульных тестов является комбинаторика. Представьте свои функции как узлы в графе и вызовите функции как ребра. main является исходным узлом, а функции, которые завершают программу, являются целевыми узлами. Количество различных видов поведения, которое может показывать ваша программа, равно количеству путей от исходного узла до любого целевого узла. Это экспоненциально по числу узлов и ребер. Это означает, что невозможно проверить все варианты поведения, которые ваша программа может отображать. Здесь проводятся модульные тесты. Каждый модульный тест тестирует один узел (вызов функции с определенным входом дает ожидаемый результат) или один фронт (вызов функции с определенным входом генерирует вызов функции соседней функции) графика , Количество требуемых тестов составляет всего O(|V|+|E|).

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

0

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

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

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

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

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

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

0

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

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

так или иначе вы DO тест. в начале кажется, что автоматическое тестирование требует больше времени, потому что вам нужно написать больше кода

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