Regression Testing

As the number of ways this plugin can be used grows, it is important to devise a way of doing better regression testing. This is where most of our effort has gone. The problem is that we can't simply alter the way any particular component works anymore. There are users that require certain behaviors and may not appreciate having a favorite feature or default setting suddenly change on them. There has also been several occasions where we've found that certain database drivers interact with the ORM/Hibernate + GORM layer in just a peculiar way that causes problems.

Most users of this plugin are using MySQL, Oracle, or PostgreSQL databases. MongoDB is also used more and more. As testing all of this databases automatically on Travis is quite hard, we test using H2 in the audit-test project and MySQL / Oracle in real projects. We also test manually with all supported major Grails versions on all SNAPSHOT- and RELEASE releases using the release.sh script. Automatic testing in all common databases was never automated. So we manually have to build the plugin, install it, then run the child-project's tests. This is bad. Why?

Primarily, it's bad because the feedback loop for changes is really really long and cumbersome. The longer the feedback loop, the more likely you are to lose the thread of the narrative you are working on. So the more likely it is that in a project where we get to work on it an hour or two at a time once or twice a month ... it means we're completely going to lose the thread of... what were we talking about again?

If you got an idea how to test the most common db's within Travis, you are welcome to share your thoughts with us. Until then, we rely on tickets in the issue tracker to maintain quality and flexibility of the plugin for all use cases which make sense.