Действительно ли выполнимо представить Разработку через тестирование (TDD) в сформировавшемся проекте? [закрытый]
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
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 ");
}
}
}
6 ответов
Создание сложной инфраструктуры насмешки, вероятно, просто скроет проблемы в Вашем коде. Я рекомендовал бы запустить с интеграционных тестов, с тестовой базы данных, вокруг областей кодовой базы, которую Вы планируете изменить. Как только у Вас есть достаточно тестов, чтобы гарантировать, что Вы ничего не повредите при внесении изменения можно начать осуществлять рефакторинг код для создания его более тестируемым.
Se также Michael Feathers превосходная книга , Работающая эффективно с унаследованным кодом , это - необходимость чтение для любого размышление о введении TDD в основу унаследованного кода.
Да Вы можете. Из Вашего описания проект находится в хорошей форме - твердый объем автоматизации функциональных испытаний является способом пойти! В некоторых аспектах его еще более полезное, чем поблочное тестирование. Помните тот TDD! = поблочное тестирование, это - все о коротких повторениях и твердых критериях допустимости.
помните, что наличие существующего и принятого проекта на самом деле делает тестирование легче - рабочее приложение является лучшей спецификацией требований. Таким образом, Вы находитесь в лучшем положении, чем кто-то, у кого просто есть клочок бумаги для работы с.
Только начинают работать над Вашими новыми требованиями/исправлениями ошибок с TDD. Помните, что будут издержки, связанные с переключением методологии (удостоверьтесь, что Ваши клиенты знают об этом!) и вероятно ожидают большое нежелание от членов команды, которые привыкли к 'старым добрым путям'.
не касаются старых вещей, если Вы не должны. Если у Вас будет запрос улучшения, который будет влиять на существующий материал тогда фактор в дополнительное время для того, чтобы сделать дополнительные вещи установки.
Лично я не вижу много значения в представлении сложной инфраструктуры для макетов - конечно, существует способ достигнуть тех же результатов в легком режиме, но это, очевидно, зависит от Ваших обстоятельств
Я думаю, что его абсолютно выполнимое вводит TDD в существующее приложение, на самом деле я недавно сделал его сам.
является самым легким кодировать новую функциональность в TDD путь и реструктуризация существующего кода для размещения этого. Таким образом, Вы запускаете с маленького раздела своего протестированного кода, но эффекты начинают распространяться через целую кодовую базу.
, Если у Вас есть ошибка, затем запишите модульный тест для репродуцирования ее, осуществив рефакторинг код по мере необходимости (если усилие действительно не не стоит того).
Лично, я не думаю, что существует любая потребность сойти с ума и попытаться модифицировать тесты в существующую систему, поскольку это может быть очень утомительно без большого количества преимущества.
, Таким образом, начните с малого, и Ваш проект станет все большим количеством зараженного теста.
Один инструмент, который может помочь Вам тестирующий унаследованный код (принимающий Вас can't\won't имеют время для рефакторинга его, является Изолятором Typemock: Typemock.com Это позволяет вводить зависимости в существующий код, не будучи должен извлечь интерфейсы и такой, потому что это не использует стандартные отражательные методы (динамический прокси и т.д.), но использование API профилировщика вместо этого. Это привыкло к тестовым приложениям, которые полагаются на sharepoint, HTTPContext и другие проблематичные области. Я рекомендую смотреть. (Я работаю dev в той компании, но это - единственный инструмент, который не вынуждает Вас осуществить рефакторинг существующий унаследованный код, экономя Вам время и деньги), я также настоятельно рекомендовал бы "Работу эффективно с унаследованным кодом" для большего количества методов.
Roy
Да Вы можете. Не делайте всего этого сразу, но представляйте, что необходимо протестировать модуль каждый раз, когда Вы касаетесь его.
можно также запустить с большего количества приемочных испытаний высокого уровня и проложить себе путь по сравнению с там (смотрите на Fitnesse для этого).
Я запустил бы с некоторых основных интеграционных тестов. Это получит закрытие сделки от остальной части штата. Тогда начните разделять части своего кода, которые имеют зависимости. Работа для использования Внедрения зависимости, поскольку это сделает Ваш код намного более тестируемым. Ошибки обработки как возможность записать тестируемый код.