[ovirt-devel] Integration tests future (and very nice alternative for the DAO fixture file)
Roman Mohr
rmohr at redhat.com
Mon Apr 18 09:10:56 UTC 2016
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().
> > >
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160418/9bee8f47/attachment-0001.html>
More information about the Devel
mailing list