Hi Roman, I really like the idea behind domain object builders.
Maybe a silly question, but how much effort would it take to autogenerate some "basic" builders from domain objects? (without DAO/Integration test related stuff like prePersist override etc.) >From the "basic" builders we could derive DAO/Integration ones as subclasses. This way, the domain object specific stuff wouldn't have to be kept in sync by hand, and we can subclass only if we need to make a builder DAO/Integration test aware. Vojtech ----- Original Message ----- > From: "Roman Mohr" <[email protected]> > To: "Eyal Edri" <[email protected]> > Cc: "Juan Antonio Hernandez Fernandez" <[email protected]>, "devel" > <[email protected]> > Sent: Thursday, April 14, 2016 1:05:25 PM > Subject: Re: [ovirt-devel] Integration tests future (and very nice > alternative for the DAO fixture file) > > > > On Thu, Apr 14, 2016 at 12:32 PM, Eyal Edri < [email protected] > wrote: > > > > Will that replace the current DAO tests running in CI? > > > For now no. What you can do with the builders reagarding to the DAO tests is > creating test scenarios for the database. So instead of adding entities to > the fixture file you can set up clean sceanrios for your tests just with the > builders in @Test or @Before methods. > > Integration tests are using Arqullian with the spring transaction manager and > will probably an extra CI job which passes the right maven flags. Arquillian > is nice here because we are much closer to a real JBoss than with Spring. > > The reason why we do not use Arquillian and only the builders for the DAO > test is that you would need a full JBoss downloaded in the background to > give us a transaction manager which does the same thing as springs > transaction manager does during the build. > > The JBoss people are currently working on modularizing all their JBoss > libraries (for JBoss Swarm) and I hope that in the future we can drop the > spring transaction manager and do everything with arquillian and the JBoss > transaction manager. > > > > On Wed, Apr 13, 2016 at 4:22 PM, Roman Mohr < [email protected] > wrote: > > > > Hi all, > > In [1] you can find some patches which are meant to improve the test writing > experience in ovirt-engine. > > They provide the following things: > > A) Domain Object builders which can be used for creating and/or persisting > domain objects [2] > B) DAO testing without writing fixtures because of the builders > C) Integration testing for commands in conjunction with a real database > Arquillian, injectable commands and the builders [3] > > # How to run what? > > A) In normal unit tests just create a new instance of a builder and use it. > This should help us to get rid of all the small createDefaultVm(), > createHostWithX() helper methods in our tests. > > B) In dao tests just inject them and go ahead. The advantage of not using the > fixture file is that we can now set up clean scenarios for every test in a > setup method. See example 2 below on how easy it is to set up a new cluster. > > C) Arquillian integration tests need to be marked with > "@Category(IntegrationTest.class)" and can inherit from > TransactionalTestBase. The @Category annotation makes sure that the > integration tests are only run when > > mvn clean verify -DskipITs=false > > is invoked. Note that these tests are then executed in the integration test > phase of maven. For them we use the maven-failsafe-plugin[5] which will also > make sure that the testing database is up to date. See [4] for more details. > > # Examples > > 1) Add a running VM to a host, persist everything to the database and load > all VMs which are running on the host: > > VDS host = vdsBuilder.cluster(persistedCluster).persist(); > vmBuilder.host(host).up().persist(); > List<VM> vms = vmDao.getAllRunningForVds(host.getId()); > > 2) Add 10 hosts with 1 GB of RAM to a cluster, persist the hosts to the > database in a DAO test: > > public class MyHostDaoTest extends BaseDaoTestCase { > > @Inject > private VdsBuilder vdsBuilder; > > @Test > public void createHosts() { > VdsBuilder builder = > vdsBuilder.cluster(persistedCluster).physicalMemory(1000); > for (int x =0; x < 10; x++){ > builder.id (Guid.newGuid()).persist(); > } > } > } > > 3) Full integration test with arquillian and the database > > @Category(IntegrationTest.class) > public class VmDaoIntegrationTest extends TransactionalTestBase { > > @Inject > VmDao vmDao; > > private final Guid VM1_GUID = > Guid.createGuidFromString("0fe4bc81-5999-4ab6-80f8-7a4a2d4bfacd"); > > @Deployment > public static JavaArchive deploy(){ > return createDeployment(); > } > > @Test > public void shouldFailOnExistingEntity() { > vmBuilder.id(VM1_GUID).cluster(clusterBuilder.reset().persist()).persist(); > // This uses assertThat from assertj: > assertThat(vmDao.get(VM1_GUID)).isNotNull(); > } > } > > 4) Using the builders in a normal unit test without a database: > > VM vm = new VmBuilder().id(Guid.newGuid()).up().build(); > > > # How to add your own Domain objects? > > There are just a few simple rules: > > 1) Your builder should extend org.ovirt.engine.core.builder.AbstractBuilder > > 2) Make sure that you only access DAOs injected into the builder during > #prePersist() and #persist(). This allows to use the #build() method also > without injections > > 3) #prePersist() should set all fields which are necessary to suffice > database constraints. The fields should only be set if they are not already > set before by the builder. When following this rule we can always persist > new objects to the database by simply calling myBuilder.reset().persist(). > > 4) Mark your builder with @Repository to make them useable for our Spring DAO > tests and our Arquillian integration tests. > > So have a look at the patches at [1] and let me know what you think about > them. > > Best Regards and happy testing, > > Roman > > [1] https://gerrit.ovirt.org/#/q/topic:integration > [2] https://gerrit.ovirt.org/#/c/47008/17 > [3] https://gerrit.ovirt.org/#/c/47007/10 > [4] https://gerrit.ovirt.org/#/c/47008/17 > [5] https://maven.apache.org/surefire/maven-failsafe-plugin/ > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > Eyal Edri > Associate Manager > RHEV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) > > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
