blocks|key|358127|text|如果你将你的逻辑与实际的GUI代码分开，你可以很容易地使用TDD来构建逻辑，并且如果你需要的话，在你的逻辑之上构建另一个界面也会容易得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358128|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|$]]

If you separate you logic from the actual GUI code, you can easily use TDD to build the logic and it will be a lot easier to build another interface on top of your logic as well, if you ever need that.

blocks|key|3139054|text|测试驱动开发更适合开发代码，而不是开发用户界面。TDD有几种不同的执行方式，但真正TDD的首选方式是首先编写测试，然后编写代码以通过测试。这是在整个开发过程中迭代完成的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139055|就我个人而言，我不确定您将如何执行UI的TDD；但是，我所在的团队对我们的UI执行自动化模拟测试。基本上，我们有一套在应用程序的最新构建上每小时运行一次的模拟。这些测试执行常见的操作，并验证某些元素、短语、对话框等是否基于一组用例正确出现。|3139056|当然，这也有它的缺点。这样做的缺点是，模拟被锁定在表示情况的代码中。它几乎没有留下变化的空间，基本上是说它希望用户对这个特性进行这个行为。|3139057|有些测试总比没有测试好，但也可以做得更好。|3139058|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Test-Driven Development lends itself more to developing code than for developing user-interfaces. There are a few different ways in which TDD is performed, but the preferred way of true TDD is to write your tests first, then write the code to pass the tests. This is done iteratively throughout development.

Personally, I'm unsure of how you would go about performing TDD for UI's; however, the team that I am on performs automated simulation tests of our UIs. Basically, we have a suite of simulations that are run every hour on the most recent build of the application. These tests perform common actions and verify that certain elements, phrases, dialogs, etc, etc, properly occur based on, say, a set of use cases.

Of course, this does have its disadvantages. The downside to this is that the simulations are locked into the code representing the case. It leaves little room for variance and is basically saying that it expects the user to do exactly this behavior with respect to this feature. 

Some testing is better than no testing, but it could be better.

blocks|key|3351841|text|是的，你可以使用TDD进行web应用的GUI测试，效果很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3351842|在测试gui时，您通常使用存根/假数据，它允许您测试gui中所有不同的状态更改。您必须将您的业务逻辑与gui分开，因为在这种情况下，您将需要模拟您的业务逻辑。|3351843|这对于捕捉那些测试人员总是忘记点击的东西来说真的很棒；他们也会导致测试失明！|3351844|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|$]]

Yes, you can use TDD with great effect for GUI testing of web apps.

When testing GUI's you typically use stub/fake data that lets you test all the different state changes in your gui. You must separate your business logic from your gui, because in this case you will want to mock out your business logic.

This is really neat for catching those things the testers always forget clicking at; they get test blindness too !

blocks|key|3351938|text|尝试测试UI组件的确切位置是没有意义的。首先是因为布局是主观的，应该由人类来“测试”。其次，因为随着UI的变化，您将不断地重写测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3351939|同样，不要测试GUI组件本身，除非您正在编写新组件。相信这个框架会做好它的工作。|3351940|相反，您应该测试构成这些组件的行为:构成应用程序的控制器和模型。在这种情况下使用TDD会促使您实现关注点分离，这样您的模型就是真正的数据管理对象，控制器就是真正的行为对象，它们都不会与UI紧密耦合。|3351941|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|$]]

Trying to test the exact placement of UI components is pointless. First because layout is subjective and should be "tested" by humans. Second, because as the UI changes you'll be constantly rewriting your tests.

Similarly, don't test the GUI components themselves, unless you're writing new components. Trust the framework to do its job.

Instead, you should be testing the behavior that underlies those components: the controllers and models that make up your application. Using TDD in this case drives you toward a separation of concerns, so that your model is truly a data management object and your controller is truly a behavior object, and neither of them are tightly coupled to the UI.

blocks|key|3139187|text|我从UI的角度来看TDD，更多的是从UI通过的最基本的接受标准来看。在一些圈子里，这被贴上了ATDD或验收测试驱动开发的标签。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3139188|我在使用TDD+for+UI时发现的最大的过度工程是，当我对使用自动化测试来测试外观和感觉问题感到兴奋时。我的建议是:不要这样！专注于测试行为:这种点击会产生这些事件，这些数据是可用的或显示的(但不是如何显示的)。外观和感觉真的是你的独立测试团队的领域。|3139189|关键是把你的精力集中在“高附加值”活动上。自动化风格测试更像是一笔债务(让它们保持最新状态)，而不是增值。|3139190|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|$]]

I look at TDD from a UI perspective more from the bare acceptance criteria for the UI to pass. In some circles, this is being labeled as ATDD or Acceptance Test Driven Development.

Biggest over-engineering I have found in using TDD for UIs is when I got all excited about using automated tests to test look and feel issues. My advice: don't! Focus on testing the behavior: this click produces these events, this data is available or displayed (but not how it's displayed). Look and Feel really is the domain of your independent testing team.

The key is to focus your energy on "High Value Add" activities. Automated style tests are more of a debt (keeping them up to date) than a value add.

blocks|key|355654|text|根据您的编辑，这里有一些关于我们在当前团队中是如何做到这一点的细节。我正在用GWT做Java，所以在Silverlight上的应用程序可能有点小问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355655|开发人员会遇到需求或bug。如果存在UI更改(L&F)，我们会快速模拟UI更改，并将其发送给产品所有者进行审批。在我们等待的同时，我们启动TDD进程。|355656|我们至少从网络测试(使用Selenium来驱动浏览器中的用户点击)开始，或者使用Concordion、FiT或类似的东西进行“无头”功能测试。一旦完成并失败了，我们就有了一个高层次的愿景，即在哪里攻击底层服务，以便使系统正常工作。|355657|下一步是挖掘并编写一些失败的单元和集成测试(我认为单元测试是独立的，没有依赖项，没有数据，等等。集成测试是对数据库进行读/写的完全连接的测试，等等)。|355658|然后，我让它自下而上地工作。听起来你的TDD背景会让你推断出这里的好处。在上升的道路上也进行了重构...|355659|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Based on your edit, here's a little more detail about how we do it on my current team. I'm doing Java with GWT, so the application to Silverlight might be a bit off.

Requirement or bug comes in to the developer. If there is a UI change (L&amp;F) we do a quick mock up of the UI change and send it over to the product owner for approval. While we are waiting on that, we start the TDD process.

We start with at least on of either a Web test (using Selenium to drive user clicks in a browser), or a "headless" functional test using Concordion, FiT or something like it. Once that's done and failing, we have a high level vision of where to attack the underlying services in order to make the system work right.

Next step is to dig down and write some failing unit and integration tests (I think of unit tests as stand-alone, no dependencies, no data, etc. Integration tests are fully wired tests that read/write to the database, etc.)

Then, I make it work from bottom up. Sounds like your TDD background will let you extrapolate the benefits here. Refactor on the way up as well....

blocks|key|358263|text|我不能和Microsoft+Silverlight交谈，但我从来不会使用TDD来解决任何布局问题，只是不值得花时间。有效的方法是使用单元测试来检查您实现的任何类型的连接、验证和UI逻辑。大多数系统为您提供了对用户采取的操作的编程访问，您可以使用这些访问来断言您的期望得到了正确的满足。例如，在按钮上调用click()方法可以执行您想要执行的任何代码。在列表视图中选择项目会将所有UI元素内容更改为此项目属性...|type|unstyled|depth|inlineStyleRanges|entityRanges|data|358264|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|$]]

I can't speak to Microsoft Silverlight, but I never use TDD for any kind of layout issues, just is not worth the time. What works well is using Unit Testing for checking any kind of wiring, validation and UI logic that you implemented. Most systems provide you with programmatic access to the actions the user takes, you can use these to assert that your expectations are correctly met. E.g. calling the click() method on a button should execute what ever code you intended. Selecting an item in a list view changes all the UI elements content to this items properties ...

blocks|key|355684|text|GUI本质上很难测试，因此正如Brian+Rasmussen建议的那样，将对话框代码与GUI代码分开。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355685|这是Humble+Dialog+Box+Pattern。|offset|length|355686|例如，您可能有一个对话框，其中输入了详细信息(例如信用卡号)，您需要对其进行验证。对于本例，您可以将使用Luhn+algorithm检查信用卡号的代码放入一个单独的对象中进行测试。(正在讨论的算法只是测试这个数字是否可信-它是为了检查转录错误而设计的。)|355687|entityMap|0|LINK|mutability|MUTABLE|url|http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf|1|http://en.wikipedia.org/wiki/Luhn_algorithm^0|0|2|P|0|0|1G|E|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

GUIs by their very nature are difficult to test, so as Brian Rasmussen suggests keep the dialog box code separate from the the GUI code.

This is the <a href="http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf" rel="nofollow noreferrer">Humble Dialog Box Pattern</a>.

For example, you may have a dialog box where details (e.g. credit card number) are input and you need to verify them. For this case you would put the code that checks the credit card number with the <a href="http://en.wikipedia.org/wiki/Luhn_algorithm" rel="nofollow noreferrer">Luhn algorithm</a> into a separate object which you test. (The algorithm in question just tests if the number is plausible - it's designed for checking for transcription errors.)

blocks|key|358296|text|我认为Ayende+Rahien的this+blog+post用一种务实和合理的方法很好地回答了我的问题。以下是这篇文章中的几句话：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|358297|例如，|358298|测试UI是一个常见的地方，它不值得花费时间和精力。|blockquote|358299|358300|..。|358301|代码质量、灵活性和更改能力通常是测试的其他因素。它们当然有帮助，但它们绝不是实现这一目标的唯一(甚至是最好的)方法。|358302|358303|测试应该只在它们为项目增加价值时使用，而不是成为主要焦点。我终于确定，使用测试驱动的UI开发可以很快成为许多根本不值得做的工作的来源。|358304|请注意，这篇文章似乎主要是关于在构建之后进行测试，而不是在构建之前(如在TDD中)-但我认为以下黄金法则仍然适用:最重要的事情值得付出最大的努力，而不重要的事情应该付出更少的努力。拥有一个经过单元测试的UI通常并不那么重要，正如Ayende所写的那样，使用TDD作为开发模型的好处可能并不是那么大--特别是当您想到开发UI通常是一个自上而下的过程时。|358305|entityMap|0|LINK|mutability|MUTABLE|url|http://ayende.com/Blog/archive/2008/12/21/the-tests-has-no-value-by-themselves-my-most-successful.aspx^0|H|E|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|16|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|18|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|19|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@]|C|$]]|$1|S|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]]]

I think <a href="http://ayende.com/Blog/archive/2008/12/21/the-tests-has-no-value-by-themselves-my-most-successful.aspx" rel="nofollow noreferrer">this blog post</a> by Ayende Rahien answers my question nicely using a pragmatic and sound approach. Here are a few quotes from the post:

<blockquote>
 Testing UI, for example, is a common
 place where it is just not worth the
 time and effort.
 
 ...
 
 Code quality, flexibility and the
 ability to change are other things
 that are often attributed to tests.
 They certainly help, but they are by
 no mean the only (or even the best)
 way to approach that.
</blockquote>

Tests should only be used when they add value to the project, without becoming the primary focus. I am finally quite certain that using test-driven development for the UI can quickly become the source of much work that is simply not worth it.

Note that it seems the post is mainly about testing AFTER things have been built, not BEFORE (as in TDD) - but I think the following golden rule still applies: The most important things deserve the greatest effort, and less important things deserve less effort. Having a unit-tested UI is often not THAT important, and as Ayende writes, the benefit of using TDD as development model is probably not so great - especially when you think of that developing an UI is normally a top-down process.

blocks|key|3352183|text|在我的工作场所，我们使用测试驱动程序，我们实际上单元测试我们的UI代码(对于web应用程序)，这要归功于Apache+Wicket的WicketTester，但它并不是测试某个描述性标签是否在文本字段之前或类似的东西，而是测试组件的层次结构是否正确(“标签在与文本字段相同的子集中”)，组件是它们应该是什么(“这个标签确实是一个标签”)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3352184|正如其他人已经说过的那样，如何将这些组件放置在UI上是由真实的人决定的，而不是程序员，特别是因为程序员倾向于做一体化/晦涩难懂的命令行工具，而不是易于使用的UI。|3352185|entityMap|0|LINK|mutability|MUTABLE|url|http://wicket.apache.org/|1|http://www.ddpoker.com/javadoc/wicket/1.4-m2/org/apache/wicket/util/tester/WicketTester.html^0|1G|D|0|1U|C|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]]]]

At my workplace we use TDD and we actually unit test our UI code (for a web application) thanks to <a href="http://wicket.apache.org/" rel="nofollow noreferrer">Apache Wicket</a>'s <a href="http://www.ddpoker.com/javadoc/wicket/1.4-m2/org/apache/wicket/util/tester/WicketTester.html" rel="nofollow noreferrer">WicketTester</a> but it's not testing that some descriptive label is before a text field or something like that, instead we test that hierarchy of the components is somewhat correct ("label is in the same subset as text field") and the components are what they're supposed to be ("this label really is a label").

Like others have already said, it's up to the real person to determine how those components are placed on the UI, not the programmer, especially since programmers have a tendency of doing all-in-one/obscure command line tools instead of UIs which are easy to use.

What are your opinions and experiences regarding using TDD when developing an user interface?

I have been pondering about this question for some time now and just can't reach a final decision. We are about to start a Silverlight project, and I checked out the <a href="http://code.msdn.microsoft.com/silverlightut/" rel="noreferrer">Microsoft Silverlight Unit Test Framework</a> with TDD in mind, but I am not sure how to apply the approach to UI-development in general - or to Silverlight in particular.

EDIT:
The question is about if it is practical thing to use TDD for UI-development, not about how to do separation of concerns.

Does TDD apply well when developing an UI?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在开发用户界面时，您对使用TDD有什么看法和经验？这个问题我已经考虑了一段时间了，就是不能做出最后的决定。我们即将开始一个Silverlight项目，我在查看时考虑到了测试驱动程序，但我不确定如何将这种方法应用于一般的UI开发-或者特别是Silverlight。问题是关于使用进行UI开发是否实用，而不是关于如何进行关注...

问在开发UI时，TDD是否适用？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在开发UI时，TDD是否适用？EN