Прежде всего, here's a great article with tips on unit testing. Во-вторых, я нашел отличный способ избежать тонких изменений в старом коде, чтобы немного переработать его, пока вы не сможете его протестировать. Один простой способ сделать это - защитить частных членов, а затем переопределить защищенное поле.
Например, у вас есть класс, который загружает некоторые вещи из базы данных во время конструктора. В этом случае вы не можете просто переопределить защищенный метод, но вы можете извлечь логику БД в защищенное поле и затем переопределить его в тесте.
public class MyClass {
public MyClass() {
// undesirable DB logic
}
}
становится
public class MyClass {
public MyClass() {
loadFromDB();
}
protected void loadFromDB() {
// undesirable DB logic
}
}
, а затем ваш тест выглядит примерно так:
public class MyClassTest {
public void testSomething() {
MyClass myClass = new MyClassWrapper();
// test it
}
private static class MyClassWrapper extends MyClass {
@Override
protected void loadFromDB() {
// some mock logic
}
}
}
Это несколько из плохого примера, потому что вы могли бы использовать DBUnit в этом случае, но я на самом деле это произошло в одном случае недавно, потому что я хотел протестировать некоторые функции, совершенно не связанные с загружаемыми данными, поэтому он был очень эффективным. Я также обнаружил, что такое раскрытие членов может быть полезным в других подобных случаях, когда мне нужно избавиться от некоторой зависимости, которая была в классе в течение длительного времени.
Я бы порекомендовал против этого решения, если вы пишете фреймворк, хотя, если вы действительно не возражаете, чтобы разоблачить членов пользователей вашего фреймворка.
Это немного взломанный, но я нашел его весьма полезным.