Replace main() with unit test to make Travis CI work

[Philipp91]

Initially, I'm just creating this pull request hoping that Travis will eventually complain about a failure in there. Later, I will update it without causing the failure, but keeping the code that catches it.

[Philipp91]

FTR, with the test code on master, everything succeeds even though it should fail:
https://travis-ci.org/cryptoexamples/rust-ring-cryptoexamples/builds/405027213
https://travis-ci.org/cryptoexamples/rust-ring-cryptoexamples/builds/405027666

[Philipp91]

Now there's a unit test which fails as expected:
https://travis-ci.org/cryptoexamples/rust-ring-cryptoexamples/builds/405030479
https://travis-ci.org/cryptoexamples/rust-ring-cryptoexamples/builds/405030512

[Philipp91]

Now the branch contains the unit test change without the change that makes the decryption fail, so it should be ready for review.

[kmindi]

Siehe TODO Kommentar, der Test sollte noch die Ausgabe prüfen.
=> Dafür sollte das Programm noch eine Ausgabe erzeugen. Anscheinend kann man das dann ganz gut mit assert_cli (https://mattgathu.github.io/testing-rust-cli-apps/) machen.

Der Key sollte vermutlich nicht in eine Datei geschrieben werden. Das sollte in einem "Key Storage" Beispiel erklärt werden. Also man müsste den Key noch mit einem Passwort schützen/verschlüsseln.

[Philipp91]

Das mit dem Prüfen der Ausgabe wäre ein bisschen umständlich.
Dafür bräuchte man Kommandozeilen-Flags, mit denen man bestimmen kann, welches Codebeispiel ausgeführt werden soll, eine main-Methode die mit einem riesigen switch-Statement die richtige Methode ausführt, und pro Codebeispiel einen Unit-Test der die Binary mit den richtigen Flags aufruft und die Ausgabe kontrolliert. Und, wie du gesagt hast, müsste man die Ausgabe auch erst einmal einfügen. Mir ist aber nicht wirklich klar, was der Mehrwert wäre.

Wenn du eine Assertion haben möchtest, könnte die Methode auch true/false zurückgeben, je nach dem ob es geklappt hat oder nicht, und der Test kann prüfen, dass es true ist. Das wäre dann eine leichtgewichtigere Art des Result<(), Error> Rückgabewerts den ich früher da hatte.

Das mit dem Key stimmt. Im analogen Java-Beispiel (https://www.cryptoexamples.com/java_string_encryption_key_based_symmetric.html) wird der Schlüssel einfach nicht gespeichert, sondern beim Ver- und Entschlüsseln aus dem gleichen Objekt im Speicher ausgelesen. Wäre das hier auch ok?
Es lässt halt für den Nutzer das Problem offen, wie man den Key speichert. Denn jedes Mal neu generieren funktioniert ja eben nicht. Und da besteht vielleicht die Gefahr, dass die Leute ihn dann hartkodieren.

[kmindi]

Ok, aber was macht der Unit test sonst? Er führt die Funktion aus.
Kannst du es so wie in diesem Java-Beispiel machen: https://www.cryptoexamples.com/java_string_encryption_password_based_symmetric.html (d.h. es gibt eine Funktion die etwas zurückgibt und eine Main-Methode (damit das Beispiel ausführbar ist, bzw. etwas demonstriert)) entsprechend der Test dazu: https://github.com/cryptoexamples/java-crypto-examples/blob/master/src/test/java/com/cryptoexamples/java/EncryptionInOneMethodTests.java#L40
Also so wie du in deinem zweiten Absatz selber vorschlägst.