我有點悖論。如何使用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