automatic testing

[andiwand]

any reason not to use release build for testing?

if not specified, marked tests should handle all different file types.

• [x] unit tests
  • [x] run tests that require input files with all files? can gtest help us? (sounds like out of scope for unit testing)
  • [ ] generate input on the fly and check constraints (wrong meta, no html output, no changes after edit)
• [x] meta
  • [x] ground truth
  • [x] regression
• [ ] decryption
  • [x] correct password (while html translation)
  • [ ] wrong password (provide wrong passwort and expect failed decryption)
• [x] html translation
  • [x] entries
  • [x] validate
  • http://www.html-tidy.org/
  • phantomjs
  • [x] ground truth
  • [x] html
  • [x] image
  • [x] regression
  • [x] html
  • [x] image (#52)
• [ ] editing (#66)
  • [ ] ground truth
  • [ ] self consistent (edit and revert)
  • [ ] regression
  • [ ] odf
  • [ ] ooxml
• [ ] code coverage
  • while unit tests
  • while translation
  • while editing
• [ ] cpu
  • cap processing time
• [ ] memory
  • valgrind
  • cap memory https://www.cryptopp.com/wiki/Pumping_Data#Low_Memory
• [ ] kpis
  • html size
  • cpu time / perf
  • memory max / mean

[TomTasche]

file size could be a KPI too!

[andiwand]

@TomTasche do you see any reason not to use release build for testing?

[TomTasche]

@TomTasche do you see any reason not to use release build for testing?

makes sense to me!