将一项测试应用于两个不同的班级

发布于 2024-08-12 03:45:17 字数 323 浏览 5 评论 0原文

我有两个不同的类共享一个公共接口。尽管功能相同,但它们内部的工作方式却截然不同。所以我自然想测试它们。

我能想到的最好的例子;我 将某些内容序列化到文件中,一个 类将其序列化为明文, 其他为 xml。数据(应该)看起来 前后相同 序列化与方法无关 使用过。

以相同方式测试两个类的最佳方法是什么?这些测试仅在实例化不同类的方式上有所不同。我不想复制整个测试、重命名并更改一行。

测试目前在 JUnit 中,但无论如何我都会将它们移植到 NUnit,所以代码并不重要。我更寻找适用于该测试套件的设计模式。

I have two different classes that share a common interface. Although the functionality is the same they work very differently internally. So naturally I want to test them both.

The best example I can come up with; I
serialize something to a file, one
class serialize it to plaintext, the
other to xml. The data (should) look
the same before and after the
serialization regardless of method
used.

What is the best approach to test both classes the same way? The tests only differs in the way that they instantiate different classes. I dont want to copy the entire test, rename it and change one line.

The tests are currently in JUnit, but Im going to port them to NUnit anyway so code doesnt really matter. Im more looking for a design pattern to apply to this test suite.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

蓝梦月影 2024-08-19 03:45:17

为测试创建一个公共抽象基测试类。

abstract class BaseTest{

 @Test
 public void featureX(){
    Type t = createInstance();
    // do something with t
 }

 abstract Type createInstance();
}

ConcreteTest extends BaseTest{

    Type createInstace(){
        return //instantiate concrete type here.
    }
}

Create a common abstract base test class for the test.

abstract class BaseTest{

 @Test
 public void featureX(){
    Type t = createInstance();
    // do something with t
 }

 abstract Type createInstance();
}

ConcreteTest extends BaseTest{

    Type createInstace(){
        return //instantiate concrete type here.
    }
}
蛮可爱 2024-08-19 03:45:17

我会通过继承或聚合重用代码。

为了拥有最短的代码,我会将测试实例创建移动到 XmlImplementationTest 类中的工厂方法,并从中继承 TextImplementationTest:

XmlImplementationTest extends TestCase
{
  Interface tested = null
  Interface createTested() { return new XmlImplementation() }
  ...
  void setUp() { tested = createTested(); }
}

TextImplementationTest extends XmlImplementationTest
{
  override Interface createTested() { return new TextImplementation() }
}

这不是完全正确的 OO 设计,因为它是 TextImplementationTest不是 XmlImplementationTest。但通常情况下你不需要关心它。

或者将测试方法调用重新定位到一些常见的实用程序类。这将涉及更多代码并且不会在测试报告中显示正确的测试类,但可能更容易调试。

I'd reuse the code either with inheritance or aggregation.

To have the shortest code, I'd move a tested instance creation to a factory method in, say, XmlImplementationTest class, and inherit a TextImplementationTest from it:

XmlImplementationTest extends TestCase
{
  Interface tested = null
  Interface createTested() { return new XmlImplementation() }
  ...
  void setUp() { tested = createTested(); }
}

TextImplementationTest extends XmlImplementationTest
{
  override Interface createTested() { return new TextImplementation() }
}

This is not completely correct OO design, as it's TextImplementationTest is NOT a XmlImplementationTest. But usually you don't need to care about it.

Or readdress the test method calls to some common utility class. This would involve more code and not show proper test class in test reports, but might be easier to debug.

来世叙缘 2024-08-19 03:45:17

我倾向于避免测试类之间的任何关系。我喜欢使测试用例(或类)尽可能保持原子性。在这里使用继承的好处并不会超过通过它获得的强耦合。

我想如果您可以分享两个类结果的验证(假设黑盒测试),那将会很有帮助。如果这两个类都能够让您设置输出流,您可以验证这一点,同时类本身写入 PrintWriter 或 FileWriter (或您的情况下需要的任何内容)。

此外,我会避免在单元测试期间创建文件,因为这可能会花费太多时间(+它可能无法在构建机器上工作),从而延迟构建。

I tend to avoid any relations between test classes. I like to keep testcases (or classes) as atomic as possible. The benefit of using inheritance here doesn't outweight the strong coupling you get by it.

I guess it would be helpful, if you could share the validation of the result of the two classes (Assuming blackbox tests). If both classes are able to let you set an outputstream, you might validate that, while the classes itself write to PrintWriter or FileWriter (or whatever you need in your cases).

Furthermore I would avoid to create files during unit-tests, because it might take too much time (+ it might not work on the build machine) and therefore delay your build.

很酷不放纵 2024-08-19 03:45:17

在 C# 中,我将使用通用辅助方法来测试这两种情况,例如:

internal static void SerializationTestHelper<T>() where T : IMySerialize
{
    T serialize = new T();
    // do some testing
}

[TestMethod]
public void XmlTest()
{
    SerializationTestHelper<XmlSerialize>();
}

[TestMethod]
public void PlainTextTest()
{
    SerializationTestHelper<PlainTextSerialize>();
}

In C#, I'd use a generic helper method to test both cases, something like:

internal static void SerializationTestHelper<T>() where T : IMySerialize
{
    T serialize = new T();
    // do some testing
}

[TestMethod]
public void XmlTest()
{
    SerializationTestHelper<XmlSerialize>();
}

[TestMethod]
public void PlainTextTest()
{
    SerializationTestHelper<PlainTextSerialize>();
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文