我的老板让我创建一个.aspx页面，用简单的文本框输入信用卡信息，以便我们可以测试CreditCard服务中的一些方法。这很好，但我认为我们可以进行单元测试。唯一的问题是，我们不需要在Web表单中输入内容，而是只需更改传递给单元测试的变量值。有人能告诉我，如果我们不使用.aspx页面来测试和输入测试数据以测试一些方法调用，是否会很疯狂？他最终会告诉我，设置单元测试需要太多时间（正如我试图告诉他我们需要进行单元测试），这是一个愚蠢的借口。
单元测试一些Web服务方法
7
- PositiveGuy
6
1祝你好运 - 希望你能赢得这场争论。 - Dror Helper
称呼你的老板的想法愚蠢和无聊并不是说服他 TDD 是正确的最好方式。 :-) 无论你是否使用单元测试，设置一个简单的 .aspx 页面手动测试特定场景可能是个好主意。 - Peter J
我站在一场失败的战斗一边。“我们不需要这样做，这是过度杀伤力了。” - PositiveGuy
我显然不会当着老板的面称他为无聊和愚蠢。我不是那么“愚蠢”。 - PositiveGuy
但这很愚蠢。我说的是实话。抱歉，我在发布时不会美化东西。 - PositiveGuy
2你写这个问题的时间，你本可以创建单元测试并说：“嘿，聪明人，看看我做了什么！” 事后请求原谅，而不是事先征得许可。另外，我认为你的老板也很愚蠢。他是个大笨蛋。但是，我不为他工作。记住，这不是失业，而是“乐趣就业”。 - user1228
8个回答
9
如果你不使用单元测试而是编写手动测试工具，那么你就有些疯了 :)
基本上，一个Web服务是通过远程协议访问的API，所以为什么不进行单元测试呢？
- Mark Seemann
1
同意。在webservice发布之外测试代码...那一层主要是配置。重要的是代码。为所有内容编写单元测试。你会感到高兴的。 - Brian Genisio
6
我之前的回答太过简略，现在我给出一个更严谨的答案：
让我们来考虑如何对该服务进行单元测试。一个真正的单元测试是一个自动化测试，测试一个单一的单元（在你的情况下，这将是没有任何后端系统，如数据库等的web服务）。正如其他人已经指出的那样，在此情况下，适当地对服务进行单元测试可能为时已晚。
这并不意味着你不能使用单元测试框架（如MSTest、xUnit.net、NUnit等）来驱动你的服务测试。让我们将那种情况与开发一次性aspx页面进行对比：
- 在两种情况下，我都假设web服务已经部署、配置和运行，因为这在aspx情况下很可能是事实。 - 在两种情况下，你都必须向测试项目添加服务引用以生成web服务代理。 - 在两种情况下，你都必须编写代码，将值应用到web服务方法的请求参数中。 - 在两种情况下，你需要调用web服务操作。
那么有什么不同呢？
- 在aspx情况下，你需要从表单字段中收集值，并将这些值分配给服务方法的参数。使用一个测试框架，你可以直接编写这些值。编写自动化测试实际上更容易。1-0 - 在aspx情况下，你需要编写代码，将响应数据写入web页面。相比之下，使用测试框架，你需要编写断言。我认为编写断言更容易，但这有点主观，所以我将这个问题视作平局 - 仍然是1-0 - 在自动化测试场景下，你需要编写许多不同值的测试，因此你需要编写更多的代码，而这与aspx选项相比则更复杂。1-1 - 使用自动化测试套件，你可以在一天中多次运行自动化测试套件，而不需要额外的工作，而在aspx情况下，你需要手动输入和手动验证每次测试运行的结果。这是测试工作量的巨大胜利。2-1（这还是保守估计）
总之，我想说，如果你不坚持在这种情况下进行真正的单元测试，而只是利用一个单元测试框架来编写自动化测试，那么你应该用自动化测试来代替aspx页面更好。开发工作量将是相同的。
对于下一个项目，你可以看看是否能从一开始就使用TDD，但那是另一场争斗。
祝你好运！
让我们来考虑如何对该服务进行单元测试。一个真正的单元测试是一个自动化测试，测试一个单一的单元（在你的情况下，这将是没有任何后端系统，如数据库等的web服务）。正如其他人已经指出的那样，在此情况下，适当地对服务进行单元测试可能为时已晚。
这并不意味着你不能使用单元测试框架（如MSTest、xUnit.net、NUnit等）来驱动你的服务测试。让我们将那种情况与开发一次性aspx页面进行对比：
- 在两种情况下，我都假设web服务已经部署、配置和运行，因为这在aspx情况下很可能是事实。 - 在两种情况下，你都必须向测试项目添加服务引用以生成web服务代理。 - 在两种情况下，你都必须编写代码，将值应用到web服务方法的请求参数中。 - 在两种情况下，你需要调用web服务操作。
那么有什么不同呢？
- 在aspx情况下，你需要从表单字段中收集值，并将这些值分配给服务方法的参数。使用一个测试框架，你可以直接编写这些值。编写自动化测试实际上更容易。1-0 - 在aspx情况下，你需要编写代码，将响应数据写入web页面。相比之下，使用测试框架，你需要编写断言。我认为编写断言更容易，但这有点主观，所以我将这个问题视作平局 - 仍然是1-0 - 在自动化测试场景下，你需要编写许多不同值的测试，因此你需要编写更多的代码，而这与aspx选项相比则更复杂。1-1 - 使用自动化测试套件，你可以在一天中多次运行自动化测试套件，而不需要额外的工作，而在aspx情况下，你需要手动输入和手动验证每次测试运行的结果。这是测试工作量的巨大胜利。2-1（这还是保守估计）
总之，我想说，如果你不坚持在这种情况下进行真正的单元测试，而只是利用一个单元测试框架来编写自动化测试，那么你应该用自动化测试来代替aspx页面更好。开发工作量将是相同的。
对于下一个项目，你可以看看是否能从一开始就使用TDD，但那是另一场争斗。
祝你好运！
- Mark Seemann
4
在aspx场景中，您需要编写代码来获取响应数据（不是使用这些调用，它们返回int或boolean）。 - PositiveGuy
我不觉得代码越多越好是问题，只有我的代码执行负责人认为是。 - PositiveGuy
改变代码并将商店转换为自动化测试几乎是不可能的。相信我。 - PositiveGuy
设置那个aspx页面，然后通过Selenium或JMeter这样的工具进行测试怎么样（链接在下面我的回答中）？当你的web服务更改时，你需要改变Selenium测试，但仍然可以随时运行并得到可衡量的结果。在Selenium的情况下，你甚至可以使用Firefox插件来简化“单元测试”的创建。 - Miha Hribar
3
如果这是一个 ASMX Web 服务，您可以尝试在 Web.config 中启用 HttpPost 协议：
这将在您访问.asmx页面时启用Web服务的测试表单。对于复杂类型，可能效果不佳；但是如果您有复杂类型，则编写单元测试比自定义表单要容易得多。
认为单元测试比Web表单更难似乎是错误的；如果您正在开发表单，则必须编写Web服务客户端代码，除了构建页面本身。
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
这将在您访问.asmx页面时启用Web服务的测试表单。对于复杂类型，可能效果不佳；但是如果您有复杂类型，则编写单元测试比自定义表单要容易得多。
认为单元测试比Web表单更难似乎是错误的；如果您正在开发表单，则必须编写Web服务客户端代码，除了构建页面本身。
- tonygambone
1
你正在做重复的工作。你需要在测试逻辑之外创建一个表单。 - PositiveGuy
3
您的老板可能希望确认该Web服务可以从.aspx页面调用，同时还可以尝试一些值。（他是否想要其他人使用的示例调用代码来创建真实的Web页面？）如果您的Web服务调用任何外部服务和/或使用数据库，编写自动化单元测试将很困难。
至于为Web服务编写真正的单元测试，我认为这次您已经输掉了比赛...。
下次，尝试在编写方法之前或之后为Web服务调用的每个方法编写单元测试。甚至无需告诉您的老板正在进行此操作，因为它将使生产工作代码更快。
一旦您证明了单元测试可以帮助您快速编写更好的代码，您可以尝试引入测试驱动开发和/或让单元测试检查源代码控制系统，并在其他人更改代码时运行它们。
您可以在老板下班后花费一些时间尝试编写单元测试。然后，当他询问为什么您的代码没有错误时，再告诉他您所做的事情。
至于为Web服务编写真正的单元测试，我认为这次您已经输掉了比赛...。
下次，尝试在编写方法之前或之后为Web服务调用的每个方法编写单元测试。甚至无需告诉您的老板正在进行此操作，因为它将使生产工作代码更快。
一旦您证明了单元测试可以帮助您快速编写更好的代码，您可以尝试引入测试驱动开发和/或让单元测试检查源代码控制系统，并在其他人更改代码时运行它们。
您可以在老板下班后花费一些时间尝试编写单元测试。然后，当他询问为什么您的代码没有错误时，再告诉他您所做的事情。
- Ian Ringrose
2
被调用的方法确实与数据库交互，但我在这里谈论的是测试方法调用，而不是数据库调用。而且，如果我想真正测试那些向数据库发送更新/获取的服务方法，我可以进行模拟。 - PositiveGuy
我喜欢您的做事方式，即使在工作之外也会继续。如果我当前无法说服这个地方，至少这种做法会在长远中对我有所帮助。 - PositiveGuy
1
- Miha Hribar
5
是的，我正在尝试立即开始。 - PositiveGuy
这是一场你肯定会输的战斗。你必须站在你老板的角度思考。我不同意。好的经理知道要将此选项纳入或至少查看它，因为这是IT中的一个很好的流程。坏的经理是那些找借口不推迟测试以便为团队和业务服务的人。我不在乎我的经理是否承受压力，或者他缺乏放慢速度并按标准进行每天工作的能力。我关心的是正确地做事，并在长期节省时间和挫折。所以不，我不会这样做，因为那个人只关心运行。 - PositiveGuy
把自己放在代码和运行管理者的位置上是IT和公司在团队和生产方面持续失败的主要原因之一。 - PositiveGuy
所以，我对那些完全无视有益于公司长远利益的想法，却用“它会拖慢我们的速度”这样的无聊借口或理由来推脱的经理毫不同情。 - PositiveGuy
我的意思是，在一些项目中，如果单元测试引入得太晚，就没有时间进行单元测试。你必须利用已有的资源。 - Miha Hribar
0
相反，您可以编写一个简单的.NET（或Java）测试来调用Web服务并检查各种情况，除了明显的好处（它是可测试的）之外，您还将拥有一种自动化的方式来检查其功能。
编写单元测试所花费的时间将通过节省重复运行相同场景的测试而得到回报。
如果您的老板还没有被说服，请向他指出TDD/unit tests effectiveness的研究结果。
如果所有其他方法都失败了，为什么不使用像soapUI这样的自动化工具，至少可以避免手动测试相同的功能。
- Dror Helper
3
是的，我告诉他我们可以稍后重新运行这些测试。 - PositiveGuy
我的老板是一位优秀的程序员，只是在一个代码和运行环境下工作。 - PositiveGuy
然后，您应该提供使用SOAP“自动化”框架 - 请参见上文。 - Dror Helper
0
在我看来，如果您创建了.aspx页面并从Web表单中获取值，那么它比单元测试更具实时性。
我希望提供此Web服务的组织已经对Web服务进行了单元测试。
我认为，您只需要创建.aspx表单并完成您的工作。
您可以对整个开发过程进行单元测试以满足您的需求。 单元测试应该由编写类/函数/ Web方法代码的人来完成，这是一个好主意。
如果您有任何问题，请告诉我。
您可以对整个开发过程进行单元测试以满足您的需求。 单元测试应该由编写类/函数/ Web方法代码的人来完成，这是一个好主意。
如果您有任何问题，请告诉我。
- Syed Tayyab Ali
4
我们为内部使用创建了Web服务。 - PositiveGuy
单元测试不应该只为了你的满意度而进行，它是为整个团队和提高测试、编码等方面而服务的。 - PositiveGuy
这不会花太多时间。这取决于你是否是单元测试的初学者。 - PositiveGuy
据我理解，无论开发人员编写了什么代码，他们都应该编写单元测试。 - Syed Tayyab Ali
0
猜测你已经输了这场战斗（我们为你感到难过）。手动创建Web服务的消费者并非最佳解决方案。
看看SoapUI。它可以消耗您的WSDL，并让您玩弄XML请求。非常容易插入Web服务进行测试，如果他们想要一个POC，那就非常合适。
- Ty.
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接