the problem with testing encryption in an integration test is that the same input should encrypt to different values each time. this makes testing without some

the problem with testing encryption in an integration test is that the same input should encrypt to different values each time. this makes testing without some kind of stubbing harder. in terms of automated tests that could have caught this error: 1). you can create a second implementation and check that it properly decrypts the output from the first implementation and check the first implementation will properly decrypt the output from the second implementation. 2) you can create output from what you believe is a known good program. then write an automated test that would decrypt this output. then write an automated test that would perform an encryption and then a decryption. this would catch a problem where the encryption and decryption routines switch to using a hardcoded string because of a bug. warning: 2) only works if the bug doesn't exist when you first write the test. :) 3). you allow the random values that making testing encryption difficult to be stubbed out then you can just encrypt plaintext and check it for equality with the ciphertext. ----> of course there is a lot more issues you should be testing for and google recently released a framework that checks for common implementation errors: https://github.com/google/wycheproof https://github.com/google/wycheproof