当我不确定某个项目的某件事时，我通常会使用一个单独的小项目，并将其放置在我的操场上，以进行需要测试的事情。你是怎样做的 ？

解决方案

我用同样的方式做。临时项目有一些缺点...要测试其他项目，必须立即设置一个新项目。我还发现游乐场是很好的参考。我经常记得我曾经尝试过一些东西，然后可以查看旧的游乐场文件，甚至可以更改它以适应新的要求。

这取决于我要尝试的内容。对于简单的算法问题，我有一个控制台应用程序，其中包含许多类，每一个我想尝试的东西都一个。这样，我将所有内容都包含在一个项目中，并且可以浏览我多年来尝试的想法和方法。当我尝试解决问题的不同解决方案时，我使用文件夹来存储新主题，并使用增加的索引(或者类似的名称，通过仅查看类名称就可以轻松查看实现的区别)来对类名进行后缀处理。

我对类所做的唯一维护工作是过滤掉不再编译的内容，但是错误的方法仅在相应的类文件中带有大量注释来标记。对我来说，这也是一种观察我的技能如何随着时间而提高的好方法……而且看旧代码也很有趣。

我有一个与GUI相关的事物以及ASP.net应用程序的类似方法，因此，我总共有三个测试项目，它们都按照上述方式组织。

我不会在操场上使用整个子项目，通常我会做一个简单的测试用例，如果能按预期工作，我会将代码合并到我的项目中。在担任程序员的这段时间里，有很多这样的文本案例，我一直都保留下来。拥有这些示例很好，因此，每当我在考虑某些问题时，我总是首先要看一下我的测试用例。

有时，我使用一个简单的控制台应用程序来测试情况。

其他时候，我克隆(或者分支)主项目，然后尝试在副本中进行操作。通常，一旦完成尝试，克隆就会被复制回(或者合并到)原始文件中。

还有一些时候，我确保将主项目签入到源代码管理中，然后再尝试一些事情。如果我不喜欢事情的进展，我会回滚更改。

我使用Ron Jeffries在" C＃的TDD历险记"中首次见到的"尖峰测试"想法。
峰值测试被编码为单元测试类，其中包含我们要尝试的代码块，而不是测试方法。
这样，我们可以通过在测试运行器中运行它们轻松地尝试一些我们不满意的代码。

我通常将尖峰测试与单元测试放在同一个项目中。一旦进入存储库，峰值测试代码可以帮助其他开发人员了解我们在生产代码中的决策。