如何在 TDD 中管理构建时间

发布于 2024-07-21 12:26:06 字数 262 浏览 9 评论 0原文

您好,在我的项目中,我们有数百个测试用例。这些测试用例是构建过程的一部分,每次签入时都会触发该测试用例,并向我们的开发人员组发送邮件。这个项目相当大,已经持续了五年多。
现在我们有这么多的测试用例,构建需要一个多小时。有些测试用例的结构不正确,重构它们后我能够大大减少运行时间,但我们有数百个测试用例并通过以下方式重构它们一个似乎有点太多了。
现在我运行一些测试用例(这需要很长时间才能执行)仅作为夜间构建的一部分,而不是作为每次签入的一部分。
我很好奇其他人是如何做到这一点的。

Hi in my project we have hundreds of test cases.These test cases are part of build process which gets triggered on every checkin and sends mail to our developer group.This project is fairly big and is been for more than five years.
Now we have so many test cases that build takes more than an hour .Some of the test cases are not structured properly and after refactoring them i was able to reduce the running time substantially,but we have hundreds of test cases and refactoring them one by one seems bit too much.
Now i run some of the test cases(which takes really long to execute) only as part of nightly build and not as part of every checkin.
I am curious as how other guys manage this .

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

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

发布评论

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

评论(3

终弃我 2024-07-28 12:26:06

也许您可以考虑保留 Oracle 数据库但从 RAM 驱动器运行它? 它不需要很大,因为它只包含测试数据。

Perhaps you could consider keeping your oracle database but running it from a ram drive? It wouldn't need to be large because it would only contain test data.

以歌曲疗慰 2024-07-28 12:26:06

我们有大约 1000 个测试,其中很大一部分是通过 REST 进行通信并访问数据库。 总运行时间约为8分钟。 一个小时似乎太多了,但我不知道你在做什么以及你的测试有多复杂。

但我认为有一种方法可以帮助你。 我们正在使用 TeamCity,它具有拥有多个构建代理的良好能力。 您可以做的是将测试项目拆分为子项目,每个子项目仅包含许多测试。 您可以使用 JNunit/NUnit 类别来分隔它们。 然后,您将配置 TeamCity,以便每个代理仅构建一种类型的子项目。 这样,您就可以并行执行测试。 如果代理很少(免费获得 3 个),您应该能够达到 20 分钟,这甚至可能是可以接受的。 如果将每个代理放入虚拟机中,您甚至可能不需要额外的机器,只需要大量 RAM。

We have about 1000 tests, large percentage of those communicating through REST and hitting database. Total run time is about 8 minutes. An hour seems excessive, but I don't know what you are doing and how complex your tests are.

But I think there is a way to help you. We are using TeamCity and it has a nice ability to have multiple build agents. What you could do is split your test project into subprojects with each subproject containing just a number of tests. You could use JNunit/NUnit Categories to separate them. Then you would configure TeamCity so that each agent would build just one type of subproject. This way, you'd get parallel execution of tests. With few agents (you get 3 for free), you should be able to get to 20 minutes, which might even be acceptable. If you put each agent into VM, you might not even require additional machines, you just need lots of RAM.

念﹏祤嫣 2024-07-28 12:26:06

我相信他在“有效地处理遗留代码”中说,如果您的测试套件花费的时间超过几分钟,那么开发人员的速度就会大大减慢,并且测试将开始被忽视。 听起来你好像掉进了那个陷阱。

您的测试用例是否针对数据库运行? 那么这很可能是性能问题的最大根源。 作为一般规则,如果可能的话,测试用例不应该执行 I/O。 依赖注入可以让您用模拟代码的数据库部分的模拟对象替换数据库对象。 这使您可以测试代码,而不必担心数据库是否设置正确。

我强烈推荐 Michael Feathers 的有效地使用旧代码。 他讨论了如何处理您似乎遇到的许多令人头疼的问题,而不必立即重构所有代码。

更新:

另一个可能的帮助是 NDbUnit 之类的东西。 我还没有广泛使用它,但它看起来很有前途:http://code.google.com /p/ndbunit/

I believe it was in "Working Effectively with Legacy Code" that he said if your test suite takes longer than a couple minutes it will slow developers down too much and the tests will start getting neglected. Sounds like you are falling into that trap.

Are your test cases running against a database? Then that's most likely your biggest source of performance problems. As a general rule, test cases shouldn't ever be doing I/O, if possible. Dependency Injection can allow you to replace a database object with mock objects that simulate the database portion of your code. That allows you test the code without worrying whether the database is setup correctly.

I highly recommend Working Effectively with Legacy Code by Michael Feathers. He discusses how to handle a lot of the headaches that you seem to be running into without having to refactor the code all at once.

UPDATE:

A another possible help would be something like NDbUnit. I haven't used it extensively yet, but it looks promising: http://code.google.com/p/ndbunit/

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