[ovirt-devel] Integration tests future (and very nice alternative for the DAO fixture file)
Roy Golan
rgolan at redhat.com
Mon Apr 18 11:54:53 UTC 2016
On Mon, Apr 18, 2016 at 12:10 PM, Roman Mohr <rmohr at redhat.com> wrote:
>
>
> On Sun, Apr 17, 2016 at 9:49 PM, Martin Mucha <mmucha at redhat.com> wrote:
>
>> Having such builders would simplify our lives for sure. But I'd really
>> try to avoid any autogeneration. I would cost lots of man hours to make it
>> happen and result won't be good. If we agree to use this approach, and
>> everyone write new methods as they're needed, 'some basic builders' come to
>> life very easy and fast.
>
>
> That's what I had in mind and I have pretty good experience with that
> pattern from previous projects. I am also against autogeneration for the
> mentioned reasons in that case. If you are on a greenfield project, Lombok
> has a nice @Builder [1] in general but it does also not fit very well here.
>
>
>> Also some places already has such similar builders — like
>> org.ovirt.engine.core.bll.network.host.HostSetupNetworksValidatorTest.HostSetupNetworksValidatorBuilder.
>>
>> M.
>>
>> ----- Original Message -----
>> > 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().
>> > >
>>
>
What I absolutely all in for this method is how elegant and easy is to
create a dao test with it. Everything you need in the test class and
quickly. Its a a big improvement cause its simple and readable and also
nice to read and work with.
+1
Auto-generating is a bit off-topic I prefer if we concentrate first on this
effort.
Roy
> > > 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
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> >
>>
>
> [6] https://projectlombok.org/features/Builder.html
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160418/5261685a/attachment-0001.html>
More information about the Devel
mailing list