验证C#WinForms代码在VisualStudio2008中工作的正确方法是什么？

我正在用WinForms c#编写一个超过9万行的应用程序。我不是一个非常有经验的程序员，在完成了几行代码后（取决于它是新的还是我以前做过很多次的事情），我在VisualStudio中用F5开始了我的项目，以验证我所做的事情是否按我希望的那样工作

例如：

如果来自SQL的数据在ListView中正确填充
如果排序列表视图按预期工作（新集成的功能）
如果docx生成工作正常，并且docx是以正确的格式创建的
如果计数正确的话

这是正确的做法吗？还是有更好的方法？现在启动我的应用程序需要5-10秒，所以这没什么大不了的，但也许有一个更好的方法比我这样做更好

我正在一台计算机上单独编写此应用程序。

通过可视化研究应用单元测试：

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

• 使用Visual Studio团队测试的单元测试演练
• 测试驱动开发指南
• 介绍Microsoft Visual Studio 2005团队系统Web测试
• 针对软件测试人员的Microsoft Visual Studio团队版
• 监视和分析负载测试结果
• 使用VisualStudio2005 Team System进行单元测试并生成单元测试框架的源代码
• Web测试编写与调试技术

---

所有找到的

考虑到代码库的大小，听起来好像没有能力从零开始完全重新启动以重新构造代码

如果您刚开始，那么我建议您使用测试驱动开发（TDD），并确保用户界面代码尽可能与代码的其余部分分开，因为以自动化方式进行测试是出了名的困难。我仍然建议你读一些关于TDD的书，还有关于

不过，听起来您想要的是一种继续使用现有代码体的方法，我将假设它的结构不适合自动化测试，因为从您所说的来看，这似乎不太可能

在这种情况下，您可能正在做正确的事情。当然，在添加特性和测试特性之间保持较短的时间间隔是很重要的，因为保持此反馈循环较短将更容易检查代码是否达到预期效果，因为您不会忘记在测试时尝试实现的目标

如果您发现编译和加载应用程序浪费了大量时间，请尝试将相关更改组合在一起，尤其是在进行简单更改时。这将有助于你获得正确的平衡

虽然我假设您不能对现有代码进行大规模更改，但您可以做的事情是以更易于测试的方式编写新代码，并为这些代码编写单元测试，但是，您必须权衡使用以多种不同编码样式结尾的代码与使用一种连贯样式的代码的成本。

如果SQL中的数据正确填充到ListView中/ 如果排序列表视图按预期工作（新集成的功能） 我从来没有使用winforms测试框架的经验（只有像Watin这样的web框架），但是我知道有很多windows窗体测试框架，例如。这些自动测试您的winforms应用程序，以测试某些文本是否出现在屏幕上，按钮单击是否将您带到预期的位置，等等

这些UI测试框架在消除每个角落的情况方面从来都不是完美的，但总是比根本没有它们有用得多

如果docx生成工作正常，并且docx的格式正确 您可以检查该文件是否存在于单元测试中。为了获得正确的格式，最好的方法可能是临时测试，也就是说，有人用脚本（通常是Excel）编写的一组测试来查看输出

如果计数正确的话

---

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

我建议探索VS2008的测试驱动设计（TDD）方面，我没有时间在这里详细讨论，我相信其他人会给你提供很多非常好的信息，但与此同时，请查看VS2008帮助中的详细信息。听起来TDD是我应该做的，但这对我的项目来说不是太过分了吗？我的意思是，我想缩短运行所需的工作量（比如不必启动整个应用程序来测试ListView列是否正确填充）。这似乎是我必须为我已经编写的代码编写测试代码/TDD从来都不过分，不管怎样，您最终都会在main中编写小测试，或者创建新项目来尝试DLL。最好马上进入TDD。而且这有利于练习；）是的，如果只测量编码新功能或更改现有功能所需的时间，则需要更长的时间。但是如果你也考虑到测试和重新测试所需的时间，你很快就会更快。特别是你会发现在几分钟内不需要中断更改。根据我的经验，当你有一个适当的测试时，你可以在更短的时间内编写剩余的代码。这是因为当您完成单元测试时，您已经完成了代码的测试，并且因为您没有浪费时间检查与您的更改不严格相关的内容。此外，如果编写正确，单元测试可以很好地添加到文档中。虽然TDD在许多情况下确实非常有用，但认为它永远都不过分是疯狂的。我强烈建议MadBoy调查TDD，权衡利弊。希望这是正确的方法并为他节省了时间，但如果他完成了98%的项目，并且永远不需要对其进行任何维护，他就永远无法证明现在进行重大重构的成本是合理的。而且，我也不想做前男友