我应该创建哪些测试来对接收和解析 XML 的库进行单元测试?

发布于 2024-10-08 02:45:14 字数 373 浏览 2 评论 0原文

我正在努力融入 TDD,并且决定重构整个类库项目,该项目解析从公开的 API 接收到的 XML。

现在我陷入了我应该进行哪些测试的困境。

您能否推荐一些我应该进行的测试,以及如何确定我将来需要测试的内容,基本经验法则?

谢谢!

using NUnit.Framework;

namespace SharpDIC.Tests
{
    [TestFixture]
    class MemberTests
    {
        [Test]
        public void Member_Should_Have_Required_Information()
        {

        }
    }
}

I'm trying to get into the groove of TDD and I've decided to refactor my entire class library project that parses XML it receives from an exposed API.

Now I'm stuck on what tests I should have.

Can you recommend some tests I should have and also how to identify what I need to test for the future, basic rule of thumb?

Thanks!

using NUnit.Framework;

namespace SharpDIC.Tests
{
    [TestFixture]
    class MemberTests
    {
        [Test]
        public void Member_Should_Have_Required_Information()
        {

        }
    }
}

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

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

发布评论

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

评论(2

被你宠の有点坏 2024-10-15 02:45:14

我通常从创建对象的测试开始。这会让事情顺利进行,并让你开始思考依赖关系。之后,考虑一下可以用代码做的最简单的事情。也许它正在解析空字符串并且什么也不做(或者抛出异常)。这是一个有效且有价值的测试。现在您已经有了一个不执行任何操作的骨架,并且首先测试添加各个功能应该不会太困难,因为您有一个现有的功能列表。

I usually start with a test that just creates the object. This gets the ball rolling and gets your thinking about dependencies going. After that, think about the simplest thing you can do with your code. Maybe it's parsing the empty string and doing nothing at all (or throwing an exception). That's a valid - and valuable - test. Now you've got a skeleton that does nothing and adding the individual features test-first shouldn't be too difficult, since you have an existing feature list.

⒈起吃苦の倖褔 2024-10-15 02:45:14

您应该编写单元测试,其中每个测试都会揭示已实现代码的一些现有行为。另外一件事可能是在开始重构 xml 解析库之前对其进行 100% 的代码覆盖。如果不查看您的 xml 库的公共接口,我无法发表太多评论。

顺便说一句,

单元测试充当安全网,帮助您捕获重构期间所做的任何破坏性功能更改。单元测试将使您能够进行重构。

You should write unit tests where each test reveals some existing behavior of the already implemented code. One additional thing could be to have 100% code coverage of your xml parsing library before you start refactoring it. I could not comment much without looking at the public interface of your xml library.

On a side note,

Unit Tests acts as a safety net which helps you to catch any breacking functional changes done during refactoring. Unit tests will enable you for refactoring.

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