blocks|key|1497968|text|像MVP和MVC这样的设计通常试图从实际的GUI中抽象出尽可能多的逻辑。关于这一点的一篇非常受欢迎的文章是迈克尔·费瑟斯写的"The+Humble+Dialog+Box"。就我个人而言，我在尝试将逻辑移出UI的过程中有过复杂的经历--有时它工作得很好，而在其他时候，它的麻烦比它的价值更多。但这有点超出了我的专业领域。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1497969|entityMap|0|LINK|mutability|MUTABLE|url|http://web.archive.org/web/20151130093108/http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf^0|1Q|N|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Designs like MVP and MVC typically try to abstract as much logic out of the actual GUI as possible. One very popular article about this is <a href="http://web.archive.org/web/20151130093108/http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf" rel="noreferrer">"The Humble Dialog Box"</a> by Michael Feathers. Personally I've had mixed experiences with trying to move logic out of the UI - sometimes it's worked very well, and at other times it's been more trouble than it's worth. It's somewhat outside my area of expertise though.

blocks|key|1497997|text|以下是一些小贴士：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1497998|尝试从GUI中删除大多数代码(具有控制器和模型对象)，这样您就可以在没有GUI的情况下对它们进行测试。|1497999|对于图形，您应该测试提供给生成图形的代码的值。|1498000|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Here is some tips:

Try to remove the most code you can from the GUI (have controller, and model object) this way you will be able to test them without the GUI.

For the graphic, you should test the value that you supply to the code that generate the graphic.

blocks|key|1498037|text|您可以使用JFCUnit来测试您的图形用户界面，但图形可能更具挑战性。我有几次拍摄了我的GUI的快照，并自动将其与以前的版本进行了比较。虽然这不能提供实际的测试，但如果自动构建不能产生预期的输出，它会提醒您。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1498038|entityMap|0|LINK|mutability|MUTABLE|url|http://jfcunit.sourceforge.net/^0|5|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can use <a href="http://jfcunit.sourceforge.net/" rel="nofollow noreferrer">JFCUnit</a> to test your GUI, but graphics can be more challenging. I have on a couple of occasions taken snapshots of my GUI and automatically compared it to a previous version. While this doesn't provide an actual test, it does alert you if an automatic build fails to produce the expected output.

blocks|key|1713132|text|您可以尝试UISpec4J，它是一个开放源代码的功能和/或单元测试库，用于基于Swing的Java应用程序...|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1713133|entityMap|0|LINK|mutability|MUTABLE|url|http://www.uispec4j.org/^0|5|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can try <a href="http://www.uispec4j.org/" rel="noreferrer">UISpec4J</a> is an Open Source functional and/or unit testing library for Swing-based Java applications...

blocks|key|1498134|text|还有Selenium+RC，它将自动测试基于web的用户界面。它将记录动作并重放它们。您仍然需要遍历与您的UI的交互，因此这对覆盖范围没有帮助，但它可以用于自动构建。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1498135|entityMap|0|LINK|mutability|MUTABLE|url|http://selenium-rc.openqa.org/^0|2|B|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

There is <a href="http://selenium-rc.openqa.org/" rel="noreferrer">Selenium RC</a>, which will automate testing a web based UI. It will record actions and replay them. You'll still need to walk through the interactions with your UI, so this will not help with coverage, but it can be used for automated builds.

blocks|key|1498188|text|据我所知，这相当复杂，而且确实取决于语言--许多语言都有自己的测试GUI的方法，但如果你真的需要测试GUI+(而不是模型/gui交互)，你经常必须模拟实际的用户点击按钮。例如，Eclipse中使用的SWT框架提供了SWTBot，已经提到过JFCUnit，Mozilla在XUL中有自己的方法来模拟这一点(从我在他们的博客上看到的，这些测试似乎相当脆弱)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1498189|有时你必须截图，并测试像素完美的渲染(我相信Mozilla这样做是为了检查正确渲染的页面)-这需要更长的设置，但这可能是你需要的图形。这样，当您更新代码和测试中断时，如果失败是真实的，您必须手动检查图像，或者您改进了图形渲染代码以生成更漂亮的图形，并需要更新屏幕截图。|1498190|entityMap|0|LINK|mutability|MUTABLE|url|http://swtbot.sourceforge.net/|1|http://jfcunit.sourceforge.net/^0|2Z|6|0|3B|7|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

From what I know, this is quite complicated, and really depends on the language - numerous languages have their own way of testing GUI, but if you really need to test the GUI (as opposed to model/gui interaction), you often have to simulate an actual user clicking buttons. For example, the SWT framework used in Eclipse provides <a href="http://swtbot.sourceforge.net/" rel="nofollow noreferrer">SWTBot</a>, <a href="http://jfcunit.sourceforge.net/" rel="nofollow noreferrer" title="JFCUnit">JFCUnit</a> has already been mentioned, Mozilla has their own way of simulating this in XUL (and from what I've read on their blogs, these tests seem to be quite brittle).

Sometimes you have to take a screenshot, and test for pixel-perfect rendering (I believe that Mozilla does this to check for correctly rendered pages) - this requires a lengthier setup, but might be what you need for the graphs. That way, when you update your code and a test breaks, you have to manually check the image if the failure was real, or you improved the graph rendering code to generate prettier graphs and need to update the screenshots.

blocks|key|1498243|text|当然，答案是使用MVC并将尽可能多的逻辑移出GUI。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1498244|这就是说，很久以前我从一位同事那里听说，当SGI将OpenGL移植到新硬件时，他们有一堆单元测试，这些单元测试会将一组原语绘制到屏幕上，然后计算帧缓冲区的MD5和。然后，可以将该值与已知的良好散列值进行比较，以快速确定API是否为每像素的准确性。|1498245|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Of course, the answer is to use MVC and move as much logic out of the GUI as possible.

That being said, I heard from a coworker a long time ago that when SGI was porting OpenGL to new hardware, they had a bunch of unit tests that would draw a set of primatives to the screen then compute an MD5 sum of the frame buffer. This value could then be compared to known good hash values to quickly determine if the API is per pixel accurate.

blocks|key|1713316|text|我从你的问题中得到的是，你正在寻找一种自动化的方法来详细地测试你的GUI行为，你给出的例子是测试曲线是否真的画得正确。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1713317|单元测试框架提供了一种进行自动化测试的方法，但我认为您想要执行的测试类型是复杂的集成测试，这些测试验证了大量类的正确行为，其中包括您不应该进行测试的GUI工具包/库的类。|1713318|您的选择在很大程度上取决于您使用的平台/工具包/框架:例如，使用Qt作为GUI框架的应用程序可以使用Squish自动执行测试。只需验证一次测试结果，随后自动执行的测试就会将结果与验证的结果进行比较。|1713319|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

What I gather from your question is that you're looking for an automated way to test your GUI behavior in detail, the example you give is testing whether a curve is actually drawn correctly. 

Unit testing frameworks provide a way to do automated testing, but I think the kind of tests you want to do are complicated integration tests that verify the correct behavior of a multitude of classes, among which the classes of your GUI toolkit/library, which you should not want to test.

Your options depend very much on what platforms/toolkits/frameworks you use: for example, an application using Qt as its GUI framework can use Squish to automate its tests. You verify the results of your tests once, and subsequent automatically executed tests compare results against the verified results.

blocks|key|1713343|text|您可以尝试使用Cucumber和Swinger，以通俗易懂的英语为Swing+GUI应用程序编写功能验收测试。Swinger在后台使用Netbeans的Jemmy库来驱动应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1713344|Cucumber允许您编写这样的测试：|1713345|+Scenario:+Dialog+manipulation
++++Given+the+frame+"SwingSet"+is+visible
++++When+I+click+the+menu+"File/About"
++++Then+I+should+see+the+dialog+"About+Swing!"
++++When+I+click+the+button+"OK"
++++Then+I+should+not+see+the+dialog+"About+Swing!"|code-block|syntax|javascript|1713346|看一看这个Swinger+video+demo，看看它的实际效果。|1713347|entityMap|0|LINK|mutability|MUTABLE|url|http://cukes.info/|1|http://github.com/demetriusnunes/swinger|2|http://blog.demetriusnunes.com/past/2009/6/9/who_said_you_cant_test_swing_apps/^0|7|8|0|G|7|1|0|0|0|5|I|2|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]|$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|16|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|M|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]|U|$5|P|Q|R|C|$S|V]]|W|$5|P|Q|R|C|$S|X]]]]

You can try to use <a href="http://cukes.info" rel="noreferrer">Cucumber</a> and <a href="http://github.com/demetriusnunes/swinger" rel="noreferrer">Swinger</a> for writing functional acceptance tests in plain english for Swing GUI applications. Swinger uses Netbeans' Jemmy library under the hood to drive the app.

Cucumber allows you to write tests like this:

<pre><code> Scenario: Dialog manipulation
 Given the frame "SwingSet" is visible
 When I click the menu "File/About"
 Then I should see the dialog "About Swing!"
 When I click the button "OK"
 Then I should not see the dialog "About Swing!"
</code></pre>

Take a look at this <a href="http://blog.demetriusnunes.com/past/2009/6/9/who_said_you_cant_test_swing_apps/" rel="noreferrer">Swinger video demo</a> to see it in action.

blocks|key|1713361|text|用于Swing和Ajax的Window+Licker|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1713362|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/windowlicker/^0|D|D|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

<a href="http://code.google.com/p/windowlicker/" rel="nofollow noreferrer">Window Licker</a> for Swing &amp; Ajax

blocks|key|1713399|text|测试是一种艺术形式。我同意应该尽可能地删除GUI的逻辑。然后，我们可以将单元测试的重点放在那里。与其他测试一样，测试也是为了降低风险。你并不总是需要测试所有的东西，但很多时候，最好的办法就是在不同的领域进行不同的测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1713400|另一个问题是，您真正想要在UI层测试什么。UI测试是最昂贵的测试，因为它通常需要更长的创建和维护时间，而且是最脆弱的。如果您在尝试绘制直线之前测试逻辑以确定坐标是否正确，那么您具体测试的是什么？如果要测试，请绘制带有红线的图形。你能给它一组预定的坐标并测试某些像素是红色还是不是红色？正如上面建议的那样，Selenium的位图比较是有效的，但我的主要关注点不是过度测试GUI，而是测试有助于创建UI的逻辑，然后专注于UI的哪些部分被破坏或可疑，并在那里进行一些测试。|1713401|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Testing is an art form. I agree the logic should be removed GUI as much as possible. We can then focus our unit testing there. Like anything else testing is about reducing risk. You dont always need to test everything but alot of times the best thing is to break the different testing up for at different areas. 

The other question is what are you really trying to test at the UI layer. UI testing is the most expensive testing because it usually takes longer to create, maintain and it is the most brittle. If you test the logic to know the coordinates are correct prior to trying to draw the line what are you testing specifically? If you want to test a graph with a red line is drawn. Can you give it a set predetermined coordinates and test if certain pixels are red or not red? As suggested above bitmap comparisons work, Selenium but my main focus would be not to over test the GUI but rather test the logic that will help create the UI and then focus on what portion of the UI breaks or is suspect and focus a handful of tests there.

blocks|key|1498378|text|测试GUI库不是您的工作。因此，您可以逃避检查屏幕上实际绘制的内容的责任，而不是检查小部件的属性，而是相信库可以准确地表示绘制的内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1498379|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's not your job to test the GUI library. So you can dodge the responsibility to check what is actually drawn on screen and check widgets' properties instead, trusting the library that they accurately represent what is drawn.

The calculations in my code are well-tested, but because there is so much GUI code, my overall code coverage is lower than I'd like. Are there any guidelines on unit-testing GUI code? Does it even make sense?

For example, there are graphs in my app. I haven't been able to figure out how to automate the testing of the graphs. It takes a human eye, AFAIK, to check if the graph is correct.

(I'm using Java Swing)

How can I unit test a GUI?

单元测试

集成测试

验收测试

Eclipse

Java

我的代码中的计算是经过良好测试的，但是因为有太多的GUI代码，所以我的总体代码覆盖率比我希望的要低。关于GUI代码的单元测试有什么指导原则吗？这有什么意义吗？例如，我的应用程序中有一些图表。我还不能想出如何自动化图形的测试。它需要一只人眼，AFAIK，来检查图形是否正确。(我使用的是Java Swing)

问如何对GUI进行单元测试？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何对GUI进行单元测试？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何对GUI进行单元测试？
EN