什么样的单元测试，在android应用程序

Question

我的应用程序主要是图形用户界面通信服务器的大部分信息。如果出现任何问题，它通常会在网络调用中或对JSON对象作出错误的假设。

单元测试不适合这些网络相关和I/O相关的任务，否则它们不会被称为单元测试。

所以我试图在我的案例中收集单元测试的观点。为什么我会测试Android按钮是否可以点击或者EditText能够看到我输入的内容？我只是不明白，如果这上面的方法传递，这我所有活动的onCreate运行，那么我知道该应用的工作原理implementating这些繁琐的测试

private void initElements(){ 
    placeButton = (Button) findViewById(R.id.currplace); 
    placeButton.setText(MainActivity.this.getString(R.string.findingLocation)); 
    placeButton.setEnabled(false); 
    selectplaceLayout = (LinearLayout)findViewById(R.id.selectplaceLayout); 
    selectplaceLayout.setVisibility(View.GONE); 
    splash = (RelativeLayout)findViewById(R.id.splashbg); 
    infoLayout = (LinearLayout)findViewById(R.id.infoLayout); 
} 

的效用。对其进行单元测试将是一件非常耗时的事情。耗费时间是因为我不熟悉jUnit和Android测试框架中的所有方法。

那么，长话短说，最重要的是什么？我应该考虑这些测试有什么特别的方法吗？到目前为止，我所见过的所有示例和教程都只是为了简洁而谈论最简单的示例，但我无法想到在主要的客户端 - 服务器应用程序中进行单元测试的任何实际用途。

我希望通过访问已经知道我已经声明和初始化的android视图来发现什么？我必须思考这个在非常有限的方式

所以，有识之士意识到

Answer 1

有很多你的问题方面的，但我的意见 - 你可能不需要在你的项目单元测试。

当您需要大量业务逻辑到您的项目时，单元测试真的很有光芒。在这种情况下，您可能希望将应用程序划分为多层（比如三层体系结构），以便为业务逻辑层添加一些自然隔离，并用单元测试的安全网络覆盖它。

这安全网覆盖了业务层的重构在你的屁股，这是你从什么单元测试（TDD可以提供一些不错的额外的副作用虽然）的主要事情之一。

但是，它并不是所有的独角兽和彩虹，单元测试可能会花费，有时它们会花费很多。良好的单元测试是孤立的（即处理小块代码）。这意味着您必须添加抽象层以便将您的类放在测试下。

这可能会对您的系统或消极系统产生积极影响。分层使得您的系统更加灵活，并且增加了复杂性。

有这样的说 - 单位测试的价值与您将在项目中引入的抽象业务逻辑的数量成正比。你也可以这样想 - 如果把抽象层添加到你的体系结构是矫枉过正的 - 不要添加单元测试 - 它们只会让事情变得更加复杂（架构和构建明智）。

根据您的描述 - 您典型的应用程序往往是一些外部服务器端的表示层。除了在android手机上呈现信息并将用户操作转换为主要业务逻辑完成（控制）的服务器端命令之外，它没有那么多。

通过这种方法，您可能编写的大多数代码都与“如何显示这个和那个”或“如何在这种情况下发送服务器信号”相关。这种代码显然很大程度上取决于平台，这意味着如果你想把它放在测试中，你将不得不嘲笑大量的Android特定的代码行为。

现在，Android是有些特定的平台。它旨在兼顾性能优化，并允许开发人员快速启动和生成应用程序。通常这意味着你使用的一些“瑞士刀”类扩展，通常这会加快编写代码的速度，但嘲笑这些类会变成一个真正的地狱。更何况，你必须了解平台如何在引擎盖下工作，以使这些模拟有用。换句话说，做这些测试的开销会很高。

测试表示层的另一个问题是，它们往往比业务层更动态地变化。当然这意味着你必须重构你的测试，这会增加更多的开销。

虽然我不得不说关于各种实用/帮助类的一件事。即使这些类属于表示层，并且依赖于Android代码，但是执行一些相当不重要的逻辑和也很容易为它们模拟和编写单元测试，但实际上这可能是一个好主意。但是，如果你确实有很多这样的代码 - 这可能表明你没有设计好你的架构/分层，并且需要重新思考你在做什么。

到底要回答你的问题，你必须先回答这些问题：

会否被过度设计补充说，从平台到应用程序中分离抽象层（好像在你的情况下，它会） ？如果是 - 不要使用单元测试 - 他们只会减慢你的速度。如果没有 - 使用它们。

你打算重构很多吗？如果这是一个拥有大量代码和维护的大型项目 - 那么您可能会投入分层和单元测试（但是，一眼看来，这似乎并不是您的情况）。如果这不是你的情况 - 不要为单元测试而烦恼，而且要快速。

您是否需要模拟平台来编写单元测试？如果是（似乎是你的情况） - 不要写单元测试 - 他们不值得付出努力。

希望这会有所帮助。