Xamarin Forms 单元测试

Question

Xamarin Forms 单元测试

c#unit-testingvisual-studio-2015xamarin.forms

14

如何为Xamarin Forms应用程序编写单元测试（与Xamarin Traditional即Xamarin.Android、Xamarin.IOS或Xamarin.UWP相对）？

有人能够对比解释一下Xamarin.Forms和Xamarin Traditional的单元测试吗？

关于如何实现Xamarin.Forms测试以及它们是否必需，或者我们是否应该针对每个平台编写单元测试，可以提供一个好的解释文章。

我已经阅读了一些文章，但没有找到从在Visual Studio中创建单元测试项目类型开始撰写并运行测试的文章。它们大多从中间开始讨论DI或ServiceLocator（例如这个http://arteksoftware.com/unit-testing-with-xamarin-forms-dependencyservice/）。或者，另一方面，它们将Xamarin.Forms与Xamarin.Android（或IOS）单元测试混合使用（例如： http://www.dsibinski.pl/2017/03/unit-testing-xamarin-application/）。或者，就像这篇文章http://www.alteridem.net/2015/12/21/testing-xamarin-projects-using-nunit-3/那样，它们将Portable和Shared混合在一起。

据我所知，我可以在VS中使用常规的Unit Test项目，使用MSTest或NUnit。或者，我可以针对每个平台编写特定于平台的单元测试。

所有这些都很令人困惑，因为作者似乎在各个方面混合使用术语。

一个带有支持示例的详细答案将不胜感激，因为我完全是这个领域的初学者。

- pixel

1

Xamarin Forms允许您使用单个UI层创建多平台应用程序。如果没有Forms，您可以共享大部分代码，但不包括UI层。由于UI层通常不适合单元测试，因此我认为在进行单元测试时，与Xamarin Forms无关的任何特定内容都不存在。 - C.Evenhuis

2

我认为答案分为三个部分。1）学习MVVM模式，以及如何在Xamarin Forms中使用它（对于.Android和.IOS也是如此）。2）模型和视图模型部分与UI无关，因此无论您使用XForms还是本机UI，它们都可以通过相同的方式进行单元测试。因此，任何单元测试文章都应该有所帮助。3）如何测试UI，其中我唯一看到的答案是Xamarin的基于云的“Xamarin.UITest”，我相信您已经知道了。很抱歉没有任何有用的链接可以提供。我的主要观点是，除了（3）之外，XForms不会改变测试。 - ToolmakerSteve

@ToolmakerSteve 谢谢你们 - cd491415

有没有将Xamarin单元测试添加到已有应用程序代码中的示例？我目前能够通过从Visual Studio添加名为UITestApp的单独项目来使用NUnit测试，然后将[Test]属性添加到各个类项目中。对于我的App项目中的每个类，我逐个将它们添加到UITestApp项目中以便运行单元测试...这种方式感觉很不正规，需要创建一个单独的项目并添加文件链接才能运行测试。 - adam

2个回答

2

请参考以下链接：

Xamarin.Forms单元测试（跨平台）
：此外，还可以观看有关创建Xamarin Forms应用程序的单元测试的视频剪辑。
Xamarin.iOS单元测试

P.S.

Xamarin.Forms应用程序通常在跨平台共享项目（便携式类库或共享项目）中定义，并与特定于平台的项目相结合。

Xamarin.Forms最适合：

需要很少特定于平台的功能的应用程序
代码共享比自定义UI更重要的应用程序
熟悉XAML的开发人员

Xamarin.iOS和Xamarin.Android最适合：

需要本地行为的交互应用程序
使用许多特定于平台的API的应用程序
自定义UI比代码共享更重要的应用程序

此链接还解释了Xamarin.Forms和Xamarin.Native之间的区别。

- rookiejava

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rabi Satter · Accepted Answer

我曾经有同样的问题，最终我采取了两个部分的策略，包括对代码进行单元测试，然后进行UI测试。

针对没有UI的代码进行单元测试，例如模型、服务等的测试。通常我都会有一个单元测试项目，并针对共享库编写单元测试。

UI测试是针对操作系统的。我有一个iOS测试项目和一个Android测试项目。我曾考虑过有一个单一的UI测试项目，那将是天堂。但我认为它不能处理每个操作系统的所有UI细节。

在构建过程中，运行单元测试。如果它们通过，则运行UI测试。我有两组测试，烟雾测试和深度测试，针对每个操作系统。烟雾测试在一小部分设备上完成。我可以快速判断构建质量，避免在不好的构建上浪费测试时间。然后，在好的构建上，在相同的少量设备上进行深层次测试。如果一切顺利，那么就在更多的设备池中进行烟雾测试。如果设备池中出现崩溃报告，则进行深度测试。如果问题设备有足够大的用户基础并继续存在问题，则将其添加到深度池测试。

我在工作中学到了很多，有着非常漫长的职业生涯，包括在微软工作7年，担任.NET Framework、.NET Framework SDK和相关技术（如ASP.NET MVC、WebAPI、Azure等）的几个团队的PM。上述构建过程是基于.NET Framework和.NET Framework SDK的构建方式。.NET的编译需要一段时间。测试运行甚至更长（考虑物理天数），因此在构建中加入快速的烟雾测试非常有用，可节省时间。有时候构建会编译并生成安装程序，但会出现问题，只有几个相对较少的测试可以指出不良构建并为QA团队节省大量时间。

下面的Rookiejava添加了一些有关学习如何编写测试的好链接。

我对设计测试的最佳建议是要愚蠢、刻薄、严格和像小妖精一样。要愚蠢，制作那些理解编程的人不会做的测试。最好的例子是我相信在x-box上发现的一个登录漏洞。有人的孩子做了一件非常奇怪的事情，不出所料地进入了他父亲的账户。所谓刻薄就是做让你发疯的事情。打击你的产品。毫不夸张地说，有一家主要的保险箱制造商，只需在特定位置敲打保险箱即可打开，而不需要密码！严格执行，不要做任何推测。如果使用案例、用户故事或了解代码应该如何工作的文档中指出fatique，那么你的测试应该只在fatique情况下通过代码，尽管我们都知道它应该是fatigue。记得把这个问题报告给使用案例/用户故事 ;) 我能给出的最大建议是像小妖精一样思考。不仅要测试正常路径是否正常，还要测试各种奇怪的输入和组合命令、按键等。我使用过的最好的测试工具是微软为Windows Mobile开发的一个测试工具。没错，就是Windows。这个工具会对应用程序的用户界面进行完全随机的操作。随机按键，自下而上输入信息，甚至以随机顺序等等。看到我和其他人无意中做出了多少推测是很有趣的。它甚至发现了一个漏洞，可以让某人完全访问我为一家政府机构工作的设备，不仅我们的团队错过了，其他外部安全测试人员也错过了。在设备交给开发外的任何人之前，我们悄悄地修补了它。