Используя “друга” - объявления для поблочного тестирования. Плохая идея?
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
Приведенный ниже код дает вам исключение с нулевым указателем.
public class School {
Student obj_Student;
public School() {
try {
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
Поскольку вы используете Obj_Student, но вы забыли инициализировать его, как в правильном коде, показанном ниже:
public class School {
Student obj_Student;
public School() {
try {
obj_Student = new Student();
obj_Student.setId(12);
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
4 ответа
Я сделал широкое применение этой техники - это означает, что мои модульные тесты могут протестировать аспекты библиотеки кода, которые не видимы нормальным потребителям.
При использовании [InternalsVisibleTo] действительно увеличивает связь, я полагаю, что (незначительное) увеличение определенно стоит усилений.
Мои модульные тесты уже сильно связываются к коду под тестом - хотя я пробую к тестам записи, которые гарантируют определенные результаты, не определенные реализации, путем доступа к вещам, не видимым постоянным потребителям, я действительно несколько ограничиваю реализацию.
Хождение другим путем, связь минимальна - в наличии эти [InternalsVisibleTo] атрибут на блоке кода, и в маркировке некоторых вещей как [1 111] внутренний вместо [1 112] частный (или защитил внутренний вместо [1 114], защитил ).
(Отмечают, что я игнорирую здесь любые конструктивные изменения, которые вызываются при помощи Поблочного тестирования, которое является целым другим обсуждением.)
Эти [InternalsVisibleTo] атрибут требует строгого именования Ваши блоки. Если Вы уже не делаете этого, можно найти это немного обременительным, поскольку сборка со строгим именем может только зависеть от других сборок со строгим именем, которые могут закончиться с Вами бывший должный изменить несколько блоков.
Разбирание в атрибуте может быть немного трудным, поскольку это должно включать открытый ключ Вашей опытной сборки. IDesign имеют полезное Друг Сборочный инструмент , который создает атрибут на Вашем буфере обмена, готовом к вставке. Рекомендуемый.
Это - единственное использование, к которому я когда-либо лично обращался InternalsVisibleTo - и это было очень, очень удобно действительно.
я не просматриваю модульные тесты как тестирование методом "черного ящика" - они уже связаны с реализацией в некоторой степени. Способность протестировать внутренние типы и методы позволяет намного более трудный фокус (меньшие единицы).
Я думаю с помощью InternalsVisibleToAttribute для включения поблочного тестирования, совершенно разумно. Моя "единица" в "поблочном тестировании" является классом, и это включает internal классы, таким образом, я хочу протестировать их. я не хочу к модульному тесту private методы , все же.
я не думаю, создавая специальный, закрытый интерфейс только для тестов, хорошая идея. Одно из значений поблочного тестирования - то, что оно дает Вам шанс думать об интерфейсе к Вашему классу с точки зрения потребителя того класса; обеспечение черного хода устраняет то преимущество.
Мое предпочтение, однако, состоит в том, чтобы поместить мои модульные тесты в тот же блок как мой производственный код. Это обычно не влияет на моего клиента, но это действительно упрощает вещи для меня, таким образом, я делаю это. Когда я делаю, это делает InternalsVisibleTo, вопрос уходит.
На самом деле Поблочное тестирование только использование, для которого я смог привести себя для использования InternalsVisibleToAttribute. С этим можно реализовать значительную часть 'частных' методов как внутреннюю вместо этого для представления их платформе поблочного тестирования для более агрессивного тестирования внутренних классом инвариантов.
я имел большой успех с этой техникой. Если ничто иное, это помогает Вам приблизиться к той мифической 100%-й цели покрытия кода, позволяя Вам вызвать закрытые методы в ситуациях, которые в других отношениях недоступны.