我有点悖论。如何使用TDD（测试第一次）进行密码散列实施？
我试图在构建实现之前使用TDD为我的密码哈希方法构建测试。但是我没有事先想出预期的价值，没有先建立实施。
当然，通过简单的哈希实现，我可以找到一个基于已知密码/ salt创建预期值的站点。
我敢打赌，解决方案是为TDD制定一个例外，并放弃首先构建我的测试。相反，构建我的实现以提供适当的salt/hash值，然后针对这些值构建我的测试以防止回归。
但我想我会张贴这个看看有没有我没有想到的解决方案。
或者，也许有人会在他们脑海中产生哈希以便首先构建测试。
我不知道你是否正在编写自己的哈希函数，比如sha-1（在这种情况下就是不这样做），或者你在第二种情况下使用外部哈希和随机函数来生成盐等你不必知道你的输出。你只是可以嘲笑你的哈希和随机提供商，并检查它们是否在你的输入和/或部分结果上调用
这实际上是我最终选择的方法，并且从未跟进过。 – 2012-07-15 23:21:09
所以，基本上你应该在TDD时知道“预期”输出。在你的情况下，预期的输出是哈希函数的结果。
如果您正在实施已知的散列算法，从他们的站点获取测试结果或者手动生成测试结果都不是问题。
如果你正在开发自己的算法。您也应该通过实现算法实现的原型来了解预期的输出。即使你不知道他们是否正确，你只是假设他们是正确的，并在测试中使用价值。如果哈希函数的实现更改，那么这些测试将变为红色。
你打算发明一种新的哈希算法吗？如果没有，那么可以使用“现有技术”来计算这些数据。 – Thilo 2012-07-09 04:50:57
许多事情都会进入散列密码。例如，许多人使用：一些随机生成的值存储w/user +一些静态编译立即数值+密码。然后，在使用RFC2898时，散列值可以根据迭代次数进行更改。如果这些变量中的任何一个发生变化，认证将会中断（因此单元测试也应该这样做）。 – 2012-07-09 04:54:32
如果你不能先写测试，你怎么知道你写的代码是正确的？你是否会接受“正确”意味着“无论这个算法的第一版产生什么”？这里有没有其他的标准可以用来编写测试？ – Domenic 2012-07-09 05:52:31