Opened 6 years ago
Last modified 6 years ago
#5394 new enhancement
Perform CI testing on OMEdit
| Reported by: | Francesco Casella | Owned by: | Adeel Asghar |
|---|---|---|---|
| Priority: | blocker | Milestone: | 2.0.0 |
| Component: | OMEdit | Version: | |
| Keywords: | Cc: |
Description
Every now and then serious issues pop up with OMEdit, such as losing code or crashing unexpectedly while working with the GUI, see, e.g. #5392, #5393. I'm always unsure whether they are existing problems being finally revealed, or rather actual new problems popping up.
For version 2.0.0, we should try hard to set up an automated testing framework for the GUI, that re-enacts pre-recorded command sequences from end-users, for example mimicking the building of new models in a library, and checks if the saved result at the end of the sequence remains the same. This should at least prevent regressions during the compiler development. We can't afford not to have any CI testing on the GUI, which is an essential part for the normal end-user experience.
I can volunteer to provide the sequences, but we need:
- a recording feature in OMEdit
- a testing feature in Hudson/Jenkins to replay the recorded sequences
A couple of options does seem to exist:
These guys https://www.froglogic.com/ seem to provide a state of the art framework for enterprises.
There are some other options available on github such as: https://github.com/antonioalecrim/qtghost if we were to roll our own.
I also think that it would be nice to have more unit tests in general. Using for instance google test or QTest would enable TDD based development both for the compiler and for the runtime