在
notorious Stack Overflow #38 podcast
Joel Spolsky谈到了对于像JPEG压缩这样的东西做多大的困难。 Bob Martin
wanted to cover如何为一个实例做TDD，例如在播客#41期间，但我不认为他们曾经得到它。从而：
如何使用TDD来开发和测试JPEG压缩？
Joel的问题是这样的。假设你想在某处设置一个引起低分辨率图像而不是高分辨率图像的地方。你将如何使用TDD来使它工作？你会写一个测试，刮了屏幕，以显示图像是在低分辨率？
原文链接：https://www.f2er.com/javaschema/282516.html当然不是。你已经知道JPEG库工作。你已经知道，如果你用正确的参数调用它，它会以低分辨率显示。你需要测试的是你设置的位被转换为对JPEG库的适当调用。所以你模拟出一个非常简单的模块由你的测试控制的JPEG库。然后设置位，并请求显示。 Mocked JPEG库将记住它是如何被调用的，然后测试可以检查以确保它被正确调用。
OK，那么你将如何测试JPEG库的内部？我不知道很多关于JPEG渲染，但我认为它是关于压缩，解压缩和位图。压缩和解压缩只是算法。算法具有来自给定输入的可预测输出。所以你设置一系列非常简单的输入，并确保你得到可预测的输出。您设置输入，以便覆盖JPEG算法的内部。同样的逻辑适用于位图。您不必在屏幕上呈现它们。简单的小位图可以渲染到测试可以检查的内存缓冲区中。简单，我的意思是SIMPLE。 3X3,5X5,8X8。简单。再次，您构造您的输入数据以覆盖大部分代码。
这些都不是火箭科学。如果是完美的没有。但是一套50个测试表明，90％的逻辑是正确的，当你想要改变时，可以产生巨大的影响。
你能完全消除手动测试吗？当然不是。但你可以显着减轻它。你可以减少手动测试的几个非常战略性的测试，而不是成千上万的痛苦的乏味的测试计划。
