2013/5/8 Stéphane Cl <[email protected]>
> @Ben
> Thanks for the info, I didn't know about Flyway. But basically I think
> that a test database creation script could be under version control, so
> that developers can check out earlier versions, recreate the corresponding
> version of the database, run tests and develop the app. I don't think I
> need to go much further for handling schema change. My biggest worry with a
> solution involving Dbunit dataset files would be the need of regenerating
> them as the database is evolving, it seems that it would still require me
> to maintain an up-to-date physical version of the test database.
>
> No matter how I look at it, maintaining a test database seems unavoidable.
> As for handling schema change in production, I will need to maintain a set
> of DDL patches as well in any case.
> I also expect every developer to have his own test database or schema and
> to be responsible for evolving it.
>
The advantage of actually having a suitable integration test database is
the fact that you might be able to re-use it for smoke tests, acceptance
tests and for plain development.
Inversely, once the test database is accepted by developers, they will
maintain it when adding new features and / or bug fixes. These various
use-cases create quite a bit of synergy, such that the overall development
efficiency and quality increases... You can only win, in the long run.
> @Lukas
> Yes I have seen your blog post about mocking records. Honestly I don't
> think it's the right direction
Me neither. As I said: There are 1-2 use-cases...
> because it's almost as much work as maintaining or populating a physical
> test database (you need to provide values for every field), you may need a
> lot of different dedicated data provider classes to fit your testing needs
> and at the end of the day, you still don't know whether your query would
> actually return the expected result in the correct form or not.
> As for integration tests, I really think it makes sense to indirectly test
> database interactions in a business application, a lot of problems can
> happen in the lower layers. I completely fail to understand why so many
> blog posters, book writers and pseudo-agile consultants keep arguing the
> opposite. Perhaps because in theory, we are all manipulating fully object
> oriented entities in memory, while persistence is ehhhm "taken care
> somewhere else (tm)".
>
Hehe, well, I have not yet heard many such claims in real life, though.
This afternoon I tried simulating a PostgreSQL database using H2, here is
> an extract of a @Before method
>
> Connection conn =
> DriverManager.getConnection("jdbc:h2:mem:test;DATABASE_TO_UPPER=false;MODE=PostgreSQL",
> "user", "password");
> RunScript.execute(conn, new FileReader("h2_version.sql"));
>
Is that "RunScript" something that might go into jOOQ? Looks like this
feature request here, to me:
https://github.com/jOOQ/jOOQ/issues/1933
If so, would you be interested in contributing this? You'll get free
maintenance by me :-)
Settings settings = new Settings()
> .withRenderSchema(false);
>
> sqlFactory = new Factory(conn, SQLDialect.H2, settings );
> PlatformRecord platformRecord = sqlFactory.newRecord(Tables.T_PLATFORMS);
> platformRecord.setCurrencyCode("CHF");
> platformRecord.setPlatformName("TestPlatform");
> platformRecord.setShopId("FAKE123");
>
> platformRecord.store();
> //insert a few more records here to have a minimal setup
>
> After that, I was able to test some business logic stuff. It's not a proof
> that such tests would work against postgresql, nevertheless it allowed me
> to detect 2 bugs. And it took me only 5 minutes to make my Postgresql DDL
> script work with H2.
> It might be able to switch from H2 to postgres by changing 2 or 3 lines in
> the Factory creation code, it can be interesting for everyday use because
> it has almost 0 dependency on your actual environment. However it probably
> won't work with less trivial database interactions. Perhaps I could create
> an H2 compatible test suite (95% of the app) and a PostgreSQL only test
> suite for the more advanced stuff using the same Jooq generated code.
>
>From my (limited) experience, I found Postgres to be quite fast for
integration tests, just in case you want to use some advanced Postgres
features not supported by H2
Cheers
Lukas
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
