logo标签列表

什么是在Visual Studio 2008中验证C# WinForms代码有效性的正确方法？

c#.netwinforms
3
我正在使用WinForms c#编写一个超过90k行代码的应用程序。我不是很有经验的程序员，根据代码的多少（无论是新的还是我已经做过很多次的），我会在Visual Studio中按F5启动项目，以验证我所做的事情是否按照我想要的方式工作。
例如: 如果从SQL中获取的数据正确地填充到ListView中， 如果ListView排序按预期工作（新集成的功能）， 如果生成docx并且docx具有适当的格式， 如果计算正确完成。
这样做是正确的方法吗？还是有更好的方法？目前启动我的应用程序大约需要5-10秒钟，所以这不是什么大问题，但也许有比我现在这样做更好的方法。
我在一台电脑上独自编写此应用程序。
我建议探索VS2008的测试驱动设计（TDD）方面，我没有时间在这里详细介绍，我相信其他人会指向大量的优秀信息，但同时请在VS2008帮助中查找详细信息。 - Lazarus
3个回答
6

测试驱动开发！

在Visual Studio中应用单元测试：使用Visual Studio Team Test进行单元测试演练

MSDN上有更多关于开发和测试的内容：

  • 使用Visual Studio Team Test进行单元测试演练
  • 测试驱动开发准则
  • 介绍Microsoft Visual Studio 2005 Team System Web测试
  • Microsoft Visual Studio Team Edition for Software Testers
  • 监视和分析负载测试结果
  • 使用Visual Studio 2005 Team System进行单元测试和生成单元测试框架的源代码
  • Web测试创作和调试技术

所有内容可在这里找到。

听起来像是我应该做TDD，但对于我的项目来说，这不是过度设计吗？我的意思是我想缩短我需要运行事物的工作量（比如不必启动整个应用程序来测试ListView列是否正确填充）。而这似乎意味着我必须为已经编写的代码编写测试代码。;/ - MadBoy
TDD从来不会过度，你最终会在主函数中编写小测试或创建新项目来尝试您的dlls。最好立即开始TDD。这对于实践也是有好处的 ;) - Filip Ekberg
2
是的，如果你只测量编写新功能或更改现有功能所需的时间，那么需要的时间会更长。但是，如果您还考虑到测试和重新测试所有内容所需的时间，您很快就会变得更快。特别是您将在几分钟内发现不想要的破坏性更改。 - Oliver
1
虽然TDD在许多情况下非常有用，但认为它永远不会过度使用是疯狂的。我强烈建议MadBoy调查TDD，并权衡收益与成本。希望这是正确的方法并节省了他的时间，但如果他的项目已经完成了98％，并且永远不需要进行任何维护，那么他无法证明现在进行重构的成本。此外，我不指望许多单人代码项目有任何文档。谁会读呢？ - Modan
你不需要为整个项目设置单元测试套件。你可以随时创建测试并在新添加的功能上应用一些方法。 - Filip Ekberg
显示剩余4条评论
1

鉴于代码库的规模，似乎没有完全从头开始重构代码的能力。

如果你在刚开始的时候，我会建议你使用测试驱动开发（TDD），并尽可能将用户界面代码与其余代码分开，因为自动化测试非常难以测试。我仍然建议您阅读一些关于TDD的文章，以及用户界面设计模式。

但从你所说的来看，似乎你想寻找的是一种通过现有代码前进的方法，我假设这种方法不适用于自动化测试，因为这似乎不太可能。

在这种情况下，你可能正在做正确的事情。确保添加功能和测试之间的时间尽可能短，有助于检查你的代码是否符合预期，因为当你进行测试时，你不会忘记自己的目标。

如果你发现编译和加载应用程序浪费了很多时间，尝试将相关更改捆绑在一起，特别是在进行简单更改时。这应该可以帮助你正确地平衡。

虽然我假设您无法对现有代码进行大规模更改，但您可能能够以更可测试的方式编写新代码，并为其编写单元测试，但您必须权衡具有多种不同编码风格的代码的成本与具有一个连贯风格的代码的成本。

尽管其他答案的投票比您的高，但我认为您给了我需要的确切答案。我肯定会研究TDD，但现在时间非常紧迫，拥有它的好处可能比预期的要小，甚至会让我更难按时完成它。 - MadBoy
1

如果从SQL中获取的数据在ListView中正确显示

如果ListView排序按预期工作（新集成的功能）

我没有使用过winforms测试框架的经验（只有像Watin这样的Web测试框架），但我知道有许多Windows窗体测试框架，例如NUnitForms。这些框架自动化测试您的winforms应用程序，以测试屏幕上是否出现某些文本，按钮单击是否将您带到预期位置等。

这些UI测试框架永远无法完美地消除每个角落的情况，但始终比根本没有它们更有用。

如果生成docx文件并且docx文件具有适当的格式

您可以在单元测试中检查文件是否存在。为了获得适当的格式-最好的方法可能是adhoc测试-即有人使用一组脚本编写的测试查看输出（通常在Excel中）。

如果计数正确

这是单元测试的主要素材，有大约6个.NET框架可用于此。其中一个已经内置于Visual Studio 2005+中。

关于查看输出的人就是我。不幸的是，我是这个项目中唯一的人，所以我所做的一切都必须由我自己测试/查看。稍后当我认为应用程序有了一些进展时，我会直接将其传递给用户，并要求他们汇报发现的问题。 - MadBoy
@MadBoy 如果你要编写有意义的测试来验证 Word 文档的布局，那么你可能需要手动测试 100 次（假设你不是在生成数百个文档，而只是几个）。 - Chris S
是的，这就是为什么我会坚持我现在所做的事情 :) - MadBoy
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接