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(). > > > > > > 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
