[ovirt-devel] Integration tests future (and very nice alternative for the DAO fixture file)

Fri Apr 15 13:28:17 UTC 2016

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" <rmohr at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "Juan Antonio Hernandez Fernandez" <jhernand at redhat.com>, "devel" <devel at ovirt.org>
> 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 < eedri at redhat.com > 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 < rmohr at redhat.com > 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
> Devel at ovirt.org
> 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
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel