On Mon, Apr 18, 2016 at 12:10 PM, Roman Mohr <[email protected]> wrote:
> > > On Sun, Apr 17, 2016 at 9:49 PM, Martin Mucha <[email protected]> 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" <[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(). >> > > >> > 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 >> > > [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 >> > >> > > [6] https://projectlombok.org/features/Builder.html > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
