在我学习可靠的软件开发的过程中，我意识到“以光速从踏板到奖牌的代码并祈祷没有真正计划的好结果”的方法行不通。
我正在寻求用扎实的实践来取代我以前的（当然也不是很好）的方法。我以前从未使用过单元测试，现在除了尝试学习金字塔（由于详尽的文档而进展顺利），我还试图了解单元测试总体上如何使我受益（将来还会添加集成测试，回归测试等）。我阅读了nosetest http://ivory.idyll.org/articles/nose-intro.html的介绍，并且（不要轻率）我看到您可以使用单元测试来测试正则表达式，并查看if a=1; b=1; now does a == b. 这就是我目前所能看到的。我不需要一个框架。我可以使用正则表达式测试器和常识来“测试”。如果我要使用单元测试来查看两个变量是否相等，那么我是否每次创建变量并将其设置为等于某个值时都必须创建一个测试？文章中的例子似乎有点武断。
我对学习单元测试的好处持开放态度，但我想知道单元测试的一些实际应用是什么。
底线：我以前从未使用过单元测试，所以请告诉我为什么我错了，应该开始使用测试。
干杯！！
单元测试可以让您确定您的代码是否符合您的期望。单元测试不是一个圣杯，它只是你可以使用的工具之一，可以让你的代码达到良好的准确性和模块化水平。
单元测试是您的期望。换句话说，您的测试将调用或调用正在测试的代码段，然后根据您预期发生（或返回）的结果（或返回值）来衡量结果（返回值等）。如果结果与您的预期不符，则您的测试有误（您的预期错误），或者被测代码未按您的预期运行。
当需要重构或维护代码时，单元测试特别有用。您可以更改代码、运行单元测试并检查您的更改是否破坏了测试。
简而言之，单元测试还有其他好处。通常你应该能够以自动化的方式运行它们，所以如果你做一个夜间构建，你可以让它们运行，然后你可以在早上检查结果。当多人可以更改或添加代码时，这在大型团队中特别有用。以适合单元测试的方式构建代码也会在构建应用程序时产生更多的解耦方法，这会减少代码异味并有助于其未来的可维护性和可扩展性。
通过测试 did_earn，我是否在测试用例中硬编码。例如，我是否会手动将 user5 作为参数传递（user5 已登录 400 次）并确保他们没有获得徽章，但 user6（500 次登录）确实获得了徽章？
是的，这正是你要做的。这意味着如果您更改内部实现，did_earn那么您的测试可以立即告诉您它是否仍然符合您的期望（它只在 500 次登录后返回true）。如果您正在测试非强类型的代码（如脚本语言），那么您还应该考虑测试如果您将字符串而不是整数等传递给函数会发生什么。
虽然它目前可能不适用于您，但您还应该查看mocking、IoC和Dependency Injection的概念，这些都是单元测试中大量使用的技术。