1

I'm working on a small escript app that converts ebook formats (.pdf, .epub) into the .mobi format for use on a Kindle, and I'm wondering how (using ExUnit) I can test that a conversion was successful without actually running the code on a real file and producing the new converted file.

For now the script just loops through the contents of a directory and converts the appropriate files into .mobi by invoking the Calibre package, although later on I would like to do the conversions myself.

FelixFortis
  • 684
  • 6
  • 16
  • Do you just want to test if a command was invoked with the correct arguments? – Dogbert Nov 21 '16 at 08:29
  • 1
    Since you haven't implemented the actual conversion logic yourself, there is really no reason to test that. I'd almost take the approach of assuming the conversion worked and just validate that you are getting the right inputs and doing the right thing after getting the file back. – Harrison Lucas Nov 21 '16 at 08:32
  • Although @HarrisonLucas is right in terms of my current implementation, I'm wondering how - in general - to test that a new file _would_ have been made/modified. When building apps that have the side effect of creating/modifying files, do we just have to accept that we won't know for sure that it works without actually running the code and then having a look ourselves? Perhaps I'm not thinking about it in the right way. – FelixFortis Nov 21 '16 at 09:09
  • 2
    Why do you _not_ want to convert a real file in your test? If you want your test to be implementation-agnostic your best option IMO is to use the public user interface to test your application (integration test with real files). For asserting the correct result you might want to create an input file and expected output file, then assert that the correct result is produced. You can accomplish this e.g. by comparing checksums of expected and actual output files - which should give you something like a poor man's [approval test](http://approvaltests.com/). – Patrick Oscity Nov 21 '16 at 12:19
  • Thanks for the comments everyone, they have helped me solidify what my actual problem was. I was worried about the overhead of making a new file every time I ran my tests, and the only thing I could think of was testing the file _in theory_ so to speak. The obvious solution is to create the file, test that it's valid, and then delete the file programatically. My bad for posting such an ambiguous question. – FelixFortis Nov 21 '16 at 13:09

0 Answers0