我正在学习 Android 中的单元测试(以及一般情况)。
为了练习，我构建了一个简单的输入验证器类，用于检查电子邮件和密码输入的有效性。
它有两种方法:
- isEmailValid(String email) - 检查电子邮件是否为空且有效。
- isPasswordValid(String password) - 检查密码是否为空
所以我想到创建以下测试:
- email = ""- 返回false
- email = null - 返回false
- email = "aaa"- 返回false
- email = "a@valid.email"- 返回true
- 密码 = ""- 返回false
- 密码 = null - 返回false
- 密码 = "pass"- 返回true
我猜对了吗？或者这是“测试过度”？
最佳答案
我想说这并不过分。这取决于它们在 JUnit 代码中的编写方式以及代码最初是如何编写的。每个测试都会检查不同的逻辑路径，并且由于 Android 以用户为中心，因此检查这些场景非常重要，因为用户会做出令人惊讶的事情。
例如，每个测试应该只执行一个断言，这通常是确保测试单个单元的良好做法。 您测试过代码的错误处理部分吗？还有可能的分支吗？
也可以看看使用 ECLEmma检查您的代码覆盖率，以检查它是否充分覆盖了代码并提供指标。这似乎仅在将 JUnit 与标准启动器一起使用时才有效，这取决于您使用的环境，以及您是否只是在没有 Android 代码的情况下进行 JUnit 测试。从使用 Roboelectric 的评论中可以找到替代方法和教程 here用于代码覆盖率。
您可能还想查看使用 Robotium执行可以测试用户交互的系统级(用户界面)测试。
我还想说阅读一般的单元测试。测试应该是隔离的，使用 Mock 对象将有助于这一点，并将改进代码中的依赖注入(inject)。例子有JMockit或Mockito 。这些将使您在使用 SQLite 等进行测试时变得更轻松。使单元测试能够专注于测试单个类将改进依赖项注入(inject)和整体设计。
测试还应该将干净的代码标准保留为应用程序代码，以便将来的用户可以理解。
关于android - 单元测试什么 - 简单的验证类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31890514/