Я должен создать новый метод тестирования для каждого утверждения?
При открытии CSV Вы получаете текстовый мастер импорта. На последнем шаге мастера необходимо быть в состоянии импортировать определенный столбец как текст, таким образом, сохраняя '00' префикс. После этого можно тогда отформатировать ячейку любой способ, которым Вы хотите.
я попробовал с Excel 2007, и это, казалось, работало.
8 ответов
Подумайте об этом так: каждый тест должен выдержать самостоятельно и реализует относительно дискретный набор функций. Если вы хотите проверить, верны ли три вещи относительно некоторого метода, который вы создали, то вам следует создать тест, который включает эти три вещи.
Таким образом, я должен категорически не согласиться с другими, кто ответил. Произвольное ограничение себя одним утверждением на тест ничего не даст, кроме как сделает ваше тестирование громоздким и утомительным. В конечном итоге это может вообще отбросить вас от тестирования - что, безусловно, будет позором: плохо для вашего проекта и карьеры.
Это не не означает, что у вас есть лицензия на создание больших, громоздких или многоцелевых процедуры тестирования. На самом деле, я не думаю, что когда-либо писал более 20 строк или около того.
Что касается определения того, какое утверждение не работает, когда их несколько в одной функции, вы заметите, что и nUnit, и MSTest дают вам и описание, и ссылка в случае сбоя утверждения, которая приведет вас прямо к нарушающей строке (для nUnit потребуется инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Оба они также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке.
плохо для вашего проекта и карьеры.Это не означает, что у вас есть лицензия на создание больших, громоздких или многоцелевых процедур тестирования. На самом деле, я не думаю, что когда-либо писал более 20 строк или около того.
Что касается определения того, какое утверждение не работает, когда их несколько в одной функции, вы заметите, что и nUnit, и MSTest дают вам и описание, и ссылка в случае сбоя утверждения, которая приведет вас прямо к нарушающей строке (для nUnit потребуется инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Обе программы также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке.
плохо для вашего проекта и карьеры.Это не означает, что у вас есть лицензия на написание больших, громоздких или многоцелевых процедур тестирования. На самом деле, я не думаю, что когда-либо писал более 20 строк или около того.
Что касается определения того, какое утверждение не работает, когда их несколько в одной функции, вы заметите, что и nUnit, и MSTest дают вам и описание, и ссылка в случае сбоя утверждения, которая приведет вас прямо к нарушающей строке (для nUnit потребуется инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Обе программы также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке.
громоздкие или многоцелевые процедуры тестирования. На самом деле, я не думаю, что когда-либо писал более 20 строк или около того.Что касается определения того, какое утверждение не работает, когда их несколько в одной функции, вы заметите, что и nUnit, и MSTest дают вам и описание, и ссылка в случае сбоя утверждения, которая приведет вас прямо к нарушающей строке (для nUnit потребуется инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Обе программы также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке.
громоздкие или многоцелевые процедуры тестирования. На самом деле, я не думаю, что когда-либо писал более 20 строк или около того.Что касается определения того, какое утверждение не работает, когда их несколько в одной функции, вы заметите, что и nUnit, и MSTest дают вам и описание, и ссылка в случае сбоя утверждения, которая приведет вас прямо к нарушающей строке (для nUnit потребуется инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Обе программы также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке.
вы заметите, что и nUnit, и MSTest дают вам как описание, так и ссылку, когда утверждение терпит неудачу, которое приведет вас прямо к нарушающей строке (nUnit потребует инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Оба они также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке. вы заметите, что и nUnit, и MSTest дают вам как описание, так и ссылку, когда утверждение не выполняется, что приведет вас прямо к нарушающей строке (для nUnit потребуется инструмент интеграции, такой как TestDriven.net ). Это упрощает определение точки отказа. Обе программы также останавливаются при первом сбое функции и дают вам возможность выполнить пошаговое руководство по отладке. testOverdraw и testNegativeWithdrawal - это два разных поведения. Они должны быть испытаны отдельно.
Хорошее практическое правило - иметь только одно действие с тестируемым методом в одном модульном тесте (не считая настроек и утверждений).
Personally I would create one test for each assertion otherwise you have to dig to find the reason for the failure rather than it being obvious from the test name.
If you have to write a few lines of code to set up a test and don't want to duplicate that then depending on your language and test framework you should be able to create a set of tests where each test will execute a block of code before it runs.
Make multiple test methods; do not combine them into one. Each of your test methods should test one behavior of the method. As you are saying, testing with a negative balance is a different behavior then testing with a positive balance. So, that would be two tests.
You want to do it this way so that when a test fails, you are not stuck trying to figure out which part in that test failed.
Я бы сделал эти два отдельных утверждения.
Первое представляет допустимую операцию, которая могла бы произойти, если бы пользователь регулярно использовал учетную запись, второе - случай, когда очистка данных не производилась. выполнено или выполнено неправильно.
Вам нужны отдельные тестовые примеры, чтобы можно было логически реализовать тестовые примеры по мере необходимости, особенно в сценариях регрессии, где выполнение всех тестов может быть чрезмерно дорогостоящим.
Один из способов сделать это - использовать отдельный метод для каждого сценария или настройки. В вашем случае вам, вероятно, понадобится один сценарий, при котором средств достаточно, и один сценарий, при котором средств недостаточно. И утверждают, что в первом все работает, а во втором не будут работать те же операции.
Из документации NUnit: «Если утверждение терпит неудачу, вызов метода не возвращается, и выдается сообщение об ошибке. Если тест содержит несколько утверждений, все, которые следуют за тем, которое не удалось, не будут выполнены. По этой причине обычно лучше попытаться использовать одно утверждение для каждого test. "
http://www.nunit.org/index.php?p=assertions&r=2.4.6
Однако ничто не заставляет вас следовать лучшим практикам. Если для этого конкретного проекта не стоит вашего времени и усилий иметь 100% детализированные тесты, где одна ошибка означает ровно один сбой теста (и наоборот), то не делайте этого. В конечном итоге это инструмент, который вы можете использовать с наилучшим соотношением затрат и выгод. Этот баланс зависит от множества переменных, специфичных для вашего сценария и каждого проекта.
I would recommend having one test method per assertion, or rather per a expected behavior. This allows to localize the erroneous code much faster, if any test fails.