测试通用类

发布于 2024-09-05 15:05:11 字数 324 浏览 4 评论 0 原文

本质上,这不仅仅是一个问题,更是一次交流意见的尝试 与其他人。我编写了一个模拟的通用历史类 浏览器历史记录的功能。我正在尝试包裹我的 在为其编写单元测试时,请考虑要走多远。我是 使用 NUnit。请在下面分享您的测试方法。

History 类的完整代码位于此处 (http://pastebin.com/ZGKK2V84)。

More than a question, per se, this is an attempt to compare notes
with other people. I wrote a generic History class that emulates
the functionality of a browser's history. I am trying to wrap my
head around how far to go when writing unit tests for it. I am
using NUnit. Please share your testing approaches below.

The full code for the History class is here (http://pastebin.com/ZGKK2V84).

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

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

发布评论

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

评论(3

思念满溢 2024-09-12 15:05:18

编写一个反映通用类的通用测试类。然后创建另一个测试类,用几个不同的类型参数实例化该测试类(值类型和某种引用类型是一个好的开始)。

Write a generic test class that mirrors the generic class. Then create another test class that instantiates that test class with a couple of different type arguments (a value type and a reference type of some sort are a good start).

半步萧音过轻尘 2024-09-12 15:05:17

在您看来,与非泛型类相比,泛型类的测试有何不同?我没有看到问题:)

只需在单元测试中填写 T 作为某种类型,例如 int ,这样你就有了一个 History; 的实例。 ,然后像平常一样测试该类的所有有趣逻辑。例如,当不存在历史时就无法后退,前进意味着您可以后退等等。通常的东西:) 如果您不确定该怎么做,请阅读一本书或阅读一些单元测试教程。

What specifically about it being a generic class makes different to test compared to a non-generic class in your eyes? I fail to see the problem :)

Just fill in T in the unit tests as some type, such as int so you have an instance of History<int>, and then test all of the interesting logic of the class as normal. E.g. Can't go backwards when no history exists, going forwards means you can move backwards and so on. The usual stuff :) Get a book or read some unit testing tutorials if you're not sure what to do.

夜空下最亮的亮点 2024-09-12 15:05:16

虽然这个问题有点模糊,但一般来说,对于这样的类,我建议至少测试以下内容:

  • 测试公共 API 中的每个方法和属性,验证每个方法和属性在添加“real”时是否适当地更改了内部集合“数据
  • 测试向每个方法添加无效数据(例如,这是否应该接受空引用?),确保您获得适当的异常或您想要的行为
  • 鉴于它是一个泛型类,我将使用值类型和引用类型(除非您决定向其中之一添加约束)

Although this question is a little vague, in general, with a class like this, I would propose testing the following, at a minimum:

  • Test each method and property in your public API, verifying that each changes the internal collections appropriately when adding "real" data
  • Test adding invalid data to each method (should this accept null references, for example?), making sure you either get appropriate exceptions or the behavior you desire
  • Given it's a generic class, I would test this with both a value type and a reference type (unless you decide to add a constraint to one or the other)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文