TDD需要自动化测试，所以我想听听其他人如何在Android项目中应用TDD？什么对您的团队有效/无效？您是如何特别自动化视觉测试的？我可以看到服务层和模型的TDD，但TDD和活动，布局的视觉变化等如何？
答案 0 :(得分：3)
猴子工具，也称为UI / Application Exerciser Monkey，在识别UI错误和错误时非常有用。在任何Android应用程序发布之前，最好在apk上运行它。
工作原理
Monkey是一个命令行工具，可以在任何模拟器实例或设备上运行。它将伪随机的用户事件流发送到系统中，作为您正在开发的应用程序软件的压力测试。要控制它，您有一个选项列表。
这些选项让您可以控制：
这是运行猴子的通用命令：
adb shell monkey [options]
//example
adb shell monkey -p your.package.name -v 500
有关详细信息，请参阅officiel android开发者网站上的link
单元测试Android应用的最佳做法：
在 ApiDemos 示例应用中，您可以找到 ActivityUnitTestCase 和 ActivityInstrumentationTestCase 类。
这些是用于测试android程序的实用程序类。
以下是参考资料的链接： ActivityInstrumentationTestCase 和 ActivityUnitTestCase
android.jar 包含用于普通旧单元测试的 JUnit 测试框架的子集。看看 ApiDemos 示例，了解如何编写和运行它。
您还可以尝试Robotium!和Robolectric
答案 1 :(得分：3)
查看SDK文档中的Spinner / SpinnerTest示例应用程序，以及Notepad示例应用程序的测试项目。还有一个Hello，测试教程。
使用ActivityInstrumentationTestCase2，而不是ActivityInstrumentationTestCase。
ActivityUnitTestCase的价值有限。它运行在一个与真正的Android系统不太相似的测试工具中。 AndroidInstrumentationTestCase2为您提供了更多工作。
android.test中的所有测试用例类都基于Junit3，而不是Junit4。您可以在线找到有关Junit3的大量文档。
android.test测试用例类模仿“单元测试”。对于某些组件（如Activity），在Android中无法使用Junit3进行真正的单元测试，因为单独使用反射无法正确实例化组件类。 ActivityInstrumentationTestCase2等类通过一些“魔法”来克服这个问题。我认为它们是与Junit3的TestCase非常相似的单元测试类。它们被称为“功能测试”，因为单元测试不应该具有外部依赖性，并且Android活动（例如）需要Android系统。我认为这是挑剔，但无论如何......
步骤：首先在POJO中定义尽可能多的内容（Plain Ol'J --- Objects）。在单元测试中测试它们。测试他们与功能测试框架（如Robotium）的交互。对任何不是Android对象的东西使用模拟。
从那里，使用来自android.test.mock的存根Android对象和您自己的存根来测试Android对象。最后，当其他所有设置完成后，使用Android测试用例来测试“框架”。
模拟Android对象并不容易实现，这就是为什么android.test和android.test.mock中的“模拟”真的是存根。
答案 2 :(得分：1)
要为Android应用TDD，Android Testing Codelab对您非常有帮助。在进行TDD之前，您需要应用良好的架构模式，如MVP，MVVP。因此，您可以从活动和片段中提取更多代码。对于活动，布局等的可视更改，您可以在代码实验室中查看seventh点。他们使用Espresso为活动和视觉布局测试做TDD。我试过了，这对我很有帮助。
奖励：检查Clean Architecture