我的问题是，你是否遵循任何行为规则进行测试，以避免未来的问题？更具体的：好的单元测试的属性是什么，或者你如何编写测试？
鼓励语言不可知的建议。
好的测试应该是一个TRIP(这个缩写是不够粘 – 我有一本书中的骗子打印输出，我不得不拉出，以确保我有这个权利..)
>自动：调用测试以及检查PASS / FAIL的结果应该是自动的
>全面：覆盖;虽然错误往往集中在代码中的某些区域，请确保您测试所有关键路径和方案..使用工具，如果你必须知道未测试的区域
>可重复：测试应每次产生相同的结果。测试不应该依赖于不可控的参数。
>独立：非常重要。
>测试应该一次只测试一件事。多个断言是可以的，只要他们都测试一个特性/行为。当测试失败时，它应该确定问题的位置。
>测试不应该依靠彼此 – 隔离。没有关于测试执行顺序的假设。在每次测试之前，通过适当地使用安装/拆卸来确保“干净的石板”
> Professional：从长远来看，您将拥有与生产一样多的测试代码(如果不是更多)，因此遵循与测试代码相同的良好设计标准。井考虑方法 – 具有意向显示名称的类，无重复，具有良好名称的测试等。
>良好的测试也运行速度快。任何需要超过半秒的运行的测试..需要处理。测试套件运行时间越长，它运行的频率就越低。更多的变化，开发者将试图偷偷在运行之间..如果有什么打破..它需要更长时间才能找出哪个更改是罪魁祸首。
更新2010-08：
>可读：这可以被认为是专业的一部分 – 但是它不能被强调。酸性测试将是找到一个不是你的团队成员的人，让他/她在几分钟内找出测试中的行为。测试需要像生产代码一样维护，所以即使需要更多的努力，也要易于阅读。测试应该是对称的(遵循模式)和简洁(每次测试一个行为)。使用一致的命名约定(例如TestDox样式)。避免杂乱的测试与“附带的细节”..成为一个极简主义者。
除此之外，其他大多数都是减少低收益工作的指南。 “不要测试您不拥有的代码(例如第三方DLL)。不要去测试getters和setters。注意成本效益比或缺陷概率。
