我想知道如何单元测试抽象类,以及扩展抽象类的类。
我是否应该通过扩展抽象类来测试它,去掉抽象方法,然后测试所有的具体方法?然后只测试我重写的方法,并在单元测试中测试扩展抽象类的对象的抽象方法?
我是否应该有一个抽象测试用例,可以用来测试抽象类的方法,并在测试用例中为扩展抽象类的对象扩展该类?
注意,我的抽象类有一些具体的方法。
我想知道如何单元测试抽象类,以及扩展抽象类的类。
我是否应该通过扩展抽象类来测试它,去掉抽象方法,然后测试所有的具体方法?然后只测试我重写的方法,并在单元测试中测试扩展抽象类的对象的抽象方法?
我是否应该有一个抽象测试用例,可以用来测试抽象类的方法,并在测试用例中为扩展抽象类的对象扩展该类?
注意,我的抽象类有一些具体的方法。
当前回答
我为抽象类和接口所做的工作如下:我编写一个测试,将对象作为具体对象使用。但是在测试中没有设置类型为X的变量(X是抽象类)。这个测试类并没有添加到测试套件中,而是它的子类,它们有一个setup-方法,将变量设置为x的具体实现。这样我就不会重复测试代码。如果需要,未使用测试的子类可以添加更多的测试方法。
其他回答
首先,如果抽象类包含一些具体的方法,我认为你应该这样做,考虑这个例子
public abstract class A
{
public boolean method 1
{
// concrete method which we have to test.
}
}
class B extends class A
{
@override
public boolean method 1
{
// override same method as above.
}
}
class Test_A
{
private static B b; // reference object of the class B
@Before
public void init()
{
b = new B ();
}
@Test
public void Test_method 1
{
b.method 1; // use some assertion statements.
}
}
我猜你可能想测试一个抽象类的基本功能…但是最好的方法是扩展类而不重写任何方法,并尽可能少地模拟抽象方法。
one way is to write an abstract test case that corresponds to your abstract class, then write concrete test cases that subclass your abstract test case. do this for each concrete subclass of your original abstract class (i.e. your test case hierarchy mirrors your class hierarchy). see Test an interface in the junit recipies book: http://safari.informit.com/9781932394238/ch02lev1sec6. https://www.manning.com/books/junit-recipes or https://www.amazon.com/JUnit-Recipes-Practical-Methods-Programmer/dp/1932394230 if you don't have a safari account.
也可以在xUnit模式中看到Testcase超类:http://xunitpatterns.com/Testcase%20Superclass.html
如果抽象类适合于您的实现,则测试(如上所述)派生的具体类。你的假设是正确的。
为了避免将来的混乱,请注意这个具体的测试类不是模拟的,而是假的。
严格来说,mock由以下特征定义:
A mock is used in place of each and every dependency of the subject class being tested. A mock is a pseudo-implementation of an interface (you may recall that as a general rule, dependencies should be declared as interfaces; testability is one primary reason for this) Behaviors of the mock's interface members -- whether methods or properties -- are supplied at test-time (again, by use of a mocking framework). This way, you avoid coupling of the implementation being tested with the implementation of its dependencies (which should all have their own discrete tests).
如果具体方法调用任何抽象方法,该策略将不起作用,您将希望分别测试每个子类的行为。否则,只要抽象类的具体方法与子类解耦,就可以像您所描述的那样扩展它并存根抽象方法。