有鼻子测试的 GUI 吗？
过去几个月我一直在使用nosetests 来运行我的Python 单元测试。
它确实可以完成工作，但对于直观地显示哪些测试正在运行或正在破坏的情况来说，它并不是很好。
我使用了其他几个基于 GUI 的单元测试框架，它们提供单元测试状态的可视化快照，并提供向下钻取功能以获取详细的错误消息。
Nosetests 将大部分信息转储到控制台，让开发人员筛选细节。
有什么建议吗？
I've been using nosetests for the last few months to run my Python unit tests.
It definitely does the job but it is not great for giving a visual view of what tests are working or breaking.
I've used several other GUI based unit test frameworks that provide a visual snap shot of the state of your unit tests as well as providing drill down features to get to detailed error messages.
Nosetests dumps most of its information to the console leaving it the developer to sift through the detail.
Any recommendations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用 rednose 插件来为您的控制台增色。 有了它，视觉反馈要好得多。
You can use rednose plugin to color up your console. The visual feedback is much better with it.
我使用 Trac + Bitten 进行持续集成，它的设置相当复杂，需要大量时间来进行 RTFM、设置和维护一切，但我可以获得很好的可视化报告，其中包含失败的测试和错误消息以及失败测试的图表，随着时间的推移，pylint 问题和代码覆盖率。
Bitten 是 Trac 的持续集成插件。 它具有主从架构。 Bitten master 与 Trac 集成并一起运行。 Bitten Slave 可以在任何与 Master 通信的系统上运行。 它会定期轮询 master 来获取构建任务。 如果有一个待处理的任务（最近有人提交了一些东西），master会向slave发送类似于ant的build.xml的“构建配方”，slave将遵循配方并返回结果。 配方可以包含诸如“从该存储库中签出代码”、“执行此 shell 脚本”、“在此目录中运行 Nosetests”等指令。
构建报告和统计数据随后显示在 Trac 中。
I've used Trac + Bitten for continuous integration, it was fairly complex setup and required substantial amount of time to RTFM, set up and then maintain everything but I could get nice visual reports with failed tests and error messages and graphs for failed tests, pylint problems and code coverage over time.
Bitten is a continuous integration plugin for Trac. It has the master-slave architecture. Bitten master is integrated with and runs together with Trac. Bitten slave can be run on any system that communicate with master. It would regularly poll master for build tasks. If there is a pending task (somebody has commited something recently), master will send "build recipe" similar to ant's build.xml to slave, slave would follow the recipe and send back results. Recipe can contain instructions like "check out code from that repository", "execute this shell script", "run nosetests in this directory".
The build reports and statistics then show up in Trac.
我知道这个问题是 3 年前提出的，但我目前正在开发一个 GUI，以便在我参与的项目中更轻松地使用鼻子测试。
我们的项目使用 PyQt 这使得使用此 GUI 变得非常简单，因为它提供了创建界面所需的所有内容。 我使用 Python 的时间并不长，但它相当容易掌握，所以如果你知道自己在做什么，只要你有时间，它就会是完美的。
您可以使用以下命令将 PyQt Designer 中创建的 .UI 文件转换为 python 脚本：
pyuic4 -x interface.ui -o interface.py您还可以获得一些不错的教程来感受 PyQt此处。 希望对某人有帮助:)
I know this question was asked 3 years ago, but I'm currently developing a GUI to make nosetests a little easier to work with on a project I'm involved in.
Our project uses PyQt which made it really simple to start with this GUI as it provides all you need to create interfaces. I've not been working with Python for long but its fairly easy to get to grips with so if you know what you're doing it'll be perfect providing you have the time.
You can convert .UI files created in the PyQt Designer to python scripts with:
pyuic4 -x interface.ui -o interface.pyAnd you can get a few good tutorials to get a feel for PyQt here. Hope that helps someone :)
我喜欢在编辑器旁边打开第二个终端，在其中我只需运行一个循环，每次任何文件更改时都会重新运行nosetests（或任何测试命令，例如普通的旧单元测试）。 然后，您可以将焦点保持在编辑器窗口中，同时每次在编辑器中点击“保存”时都会看到测试输出更新。
我不确定OP所说的“向下钻取”是什么意思，但就我个人而言，我从测试输出中需要的只是失败回溯，当然，每当测试失败时都会显示回溯。
当您的代码和测试编写良好时，这尤其有效，因此绝大多数测试只需几毫秒即可运行。 我可能会在编辑或调试时按如上所述循环运行这些快速单元测试，然后在最后（就在提交之前）手动运行任何长时间运行的测试。
你可以使用 Bash 'watch' 手动重新运行测试（但这只是每 X 秒运行一次。这很好，但它不够快，不足以让我高兴。）
或者我写了一个快速的 python 包 'rerun'，它会轮询文件系统更改，然后重新运行您给出的命令。 轮询更改并不理想，但它很容易编写，完全跨平台，如果你告诉它每 0.25 秒轮询一次，它会相当快，即使对于大型项目，也不会导致我任何明显的滞后或系统负载（例如Python源代码树），甚至在复杂的情况下也能工作（见下文。）
https://pypi.python.org/pypi/rerun/
第三种替代方法是使用一个更通用的“等待文件系统更改”程序，例如“看门狗”，但这对于我的需求来说似乎很重要，并且像这样侦听文件系统事件的解决方案有时无法按我的预期工作（例如，如果Vim通过以下方式保存文件）将 tmp 保存在其他地方然后将其移动到位，有时发生的事件不是您期望的。）因此“重新运行”。
I like to open a second terminal, next to my editor, in which I just run a loop which re-runs nosetests (or any test command, e.g. plain old unittests) every time any file changes. Then you can keep focus in your editor window, while seeing test output update every time you hit 'save' in your editor.
I'm not sure what the OP means by 'drill down', but personally all I need from the test output is the failure traceback, which of course is displayed whenever a test fails.
This is especially effective when your code and tests are well-written, so that the vast majority of your tests only take milliseconds to run. I might run these fast unit tests in a loop as described above while I edit or debug, and then run any longer-running tests manually at the end, just before I commit.
You can re run tests manually using Bash 'watch' (but this just runs them every X seconds. Which is fine, but it isn't quite snappy enough to keep me happy.)
Alternatively I wrote a quick python package 'rerun', which polls for filesystem changes and then reruns the command you give it. Polling for changes isn't ideal, but it was easy to write, is completely cross-platform, is fairly snappy if you tell it to poll every 0.25 seconds, doesn't cause me any noticeable lag or system load even with large projects (e.g. Python source tree), and works even in complicated cases (see below.)
https://pypi.python.org/pypi/rerun/
A third alternative is to use a more general-purpose 'wait on filesystem changes' program like 'watchdog', but this seemed heavyweight for my needs, and solutions like this which listen for filesystem events sometimes don't work as I expected (e.g. if Vim saves a file by saving a tmp somewhere else and then moving it into place, the events that happen sometimes aren't the ones you expect.) Hence 'rerun'.