[ovirt-devel] Integration tests future (and very nice alternative for the DAO fixture file)
Roman Mohr
rmohr at redhat.com
Thu Apr 14 11:05:25 UTC 2016
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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160414/d4a82eff/attachment-0001.html>
More information about the Devel
mailing list