关于 Android 和 TDD 的困惑
我目前正在阅读有关测试驱动开发的书籍和文章，包括 Android 开发和一般 TDD。我对测试 GUI 有点困惑。
在本书中，作者甚至为示例应用程序的 GUI 设计编写了测试。对于诸如“EditText 的边距应为 5 像素宽”之类的情况。这真的有道理吗？我可以理解为特定功能编写测试的价值（例如，我的单位转换器应用程序是否正确地将 5 米转换为英寸？），但我是否应该真正测试我是否在布局 xml 文件中正确定义了 UI 小部件？
我通常需要开发比 2-EditTexts-under-each-other 场景复杂得多的 UI。我认为编写测试来检查我是否将字体大小定义为 22dip 完全是浪费时间。我有错误的想法吗？
I'm currently reading books and articles about Test Driven Development, both in the case of Android development and about TDD in general. I'm a bit confused about testing the GUI.
In this book the author writes test even for designing the GUI for an example application. For things like "an EditText's margin should be 5 pixels wide". Does this really make sense? I can understand the value in writing test for specific functions (e.g. does my unit converter app convert 5 meters correctly into inches?), but should I really test if I defined my UI widgets correctly in the layout xml file?
I usually have to develop UIs that are much more complex than the 2-EditTexts-below-each-other scenario. I think it'd be a complete waste of time to write tests to check if I defined the font sizes to be 22dip or not. Am I getting the wrong idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
测试你认为可以打破的东西。如果您认为 EditText 的边距不会改变 - 不用担心。但请考虑一下它可以改变的方式。除了更改 XML 中的值这一显而易见的做法之外，为了简单性、一致性和减少行数，您可能会决定使用样式和主题。现在，单个元素的边距可以更改，因为它的主题发生了变化 - 或者因为它所基于的主题发生了变化，等等。
我认为你是对的；听起来这本书（我还没读过）正在选择一个玩具示例，也许是为了教学的清晰度。将该示例扩展到实际项目而不应用一点常识调整可能是不合适的。
Test what you think can break. If you don't think the EditText's margin will ever change - don't worry about it. But think about the ways it could change. Beyond the obvious one of changing the value in the XML, you might decide for the sake of simplicity, consistency, and reduced line count that you want to use styles and themes. Now that individual element's margin can change because its theme changed - or because the theme on which it was based changed, etc.
I think you're right; it sounds like the book (which I haven't read) is choosing a toy example, perhaps for pedagogic clarity. Extending that example to real projects without applying a little common sense adjustment may be inappropriate.