Как вы знаете, что тестировать при написании модульных тестов? [закрыто]
NullPointerException s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException. Они наиболее распространены, но другие способы перечислены на странице NullPointerException javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main я явно устанавливаю ссылку Object obj равной null. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
35 ответов
Я второй тест что-либо, что может возможно повредиться и не писать глупые тесты. Но самый важный принцип является тестом что-либо, что Вы находите, повреждается: если некоторый метод ведет себя, странно пишут тест для выделения набора данных, который заставляет его перестать работать, затем исправить ошибку и наблюдать, что панель идет зеленая. Также протестируйте "граничные" значения данных (пустой указатель, 0, MAX_INT, пустые списки, безотносительно).
Я не могу говорить за C# specificly, но когда я пишу модульные тесты, я тестирую КАЖДЫЙ вход, даже те, которых пользователь не делает, тот способ, которым я знаю, как предотвратить мои собственные ошибки.
При записи модульных тестов или действительно любого теста, Вы определяете, что протестировать путем рассмотрения граничных условий того, что Вы тестируете. Например, у Вас есть функция, вызванная is_prime. К счастью, это делает то, что это - имя, подразумевает и говорит Вам, является ли целочисленный объект главным или нет. Для этого я предполагаю, что Вы используете объекты. Теперь, мы должны были бы проверить, что допустимые результаты произошли для известного диапазона главных и неглавных объектов. Это - Ваша начальная точка.
В основном посмотрите на то, что должно произойти с функцией, методом, программой или сценарием, и затем в том, чего не должно определенно происходить с тем же самым кодом. Это - основание для Вашего теста. Просто будьте готовы изменить свои тесты, поскольку Вы становитесь более хорошо осведомленными относительно того, что должно происходить с Вашим кодом.
Написание кода, которое не имеет никакого значения, всегда является плохой идеей. Так как предложенный тест не добавляет значения к Вашему проекту (или очень близко к нему). Затем Ваш тратят впустую бесценное время, что Вы могли потратить написание кода, которое на самом деле приносит значение.
Лучшее практическое правило, которое я видел, - проверять все, что вы не можете определить с первого взгляда, наверняка будет работать правильно. Что-нибудь еще, и вы закончите тестирование языка / среды.