Joomla! 虫团队已经蓬勃发展了大约五个月，一切都非常顺利。在大多数情况下，我们一直在使用手动测试技术，这只是因为它快速、简单且灵活。有几个人对单元测试感兴趣，特别是对于维护程序，但在很大程度上，单元测试还没有流行起来。

好吧，我承认，甚至我自己也对单元测试的价值表示怀疑。我知道它有好处，但我真的在想，付出所有努力来构建单元测试是否真的值得。然后，我遇到了 JCache 的问题。补丁很容易修复，但我不知道如何彻底测试这个补丁。接着，我想到，也许这是著名的单元测试的一个很好的候选者！

意识到这是一个完美的试火机会，可以检验 Alan Langford 和其他人在 Joomla! 单元测试框架 上的辛勤工作，我联系了 Alan，看看我们能做些什么来测试这些 JCache 问题。在几小时之内（在专家的显著帮助下），我为 JCache 的各个方面编写了一系列测试。结果表明，测试不仅确认了补丁确实修复了那些问题，而且，作为一个额外的好处，测试还揭示了我们有几个不知道的其他问题。

通过投入两个小时编写这些单元测试，我不仅能够验证这个补丁，而且还发现了数月稳定版本使用期间未曾暴露的几个问题。（是的，这些问题将在Joomla! 1.5.4中修复）。对我来说，单元测试的价值已经得到了证实。单元测试不仅值得做，而且是必要的！手动测试是很好的，但单元测试能发现手动测试不可能找到的问题。

那么，理想的测试场景是什么呢？我认为应该是手动测试和单元测试的结合。手动测试仍然有它的位置，用于验证自动化测试不切实际的问题类型，例如可用性问题、设计或样式验证。然而，单元测试能轻易捕捉到数月的手动测试都无法发现的许多问题。最佳的测试方法是结合两者的优点；对于可以隔离的区域使用单元测试，对于整个系统/外部交互使用手动测试。

Bug Squad展示了基于测试的维护程序如何能迅速显著地提高项目的稳定性。将这些方法与坚实的单元测试相结合，无疑将打造出一个更好的平台。

要了解更多关于Bug Squad的信息，请查看Wiki和Google Group。鼓励社区成员加入进来，帮助Bug Squad。要开始参与，请联系Wilco Jansen或者我。欢迎您的参与！