Integration tests future (and very nice alternative for the DAO fixture file)
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/
Will that replace the current DAO tests running in CI? On Wed, Apr 13, 2016 at 4:22 PM, Roman Mohr <rmohr@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@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)
On Thu, Apr 14, 2016 at 12:32 PM, Eyal Edri <eedri@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@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@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)
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@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com>, "devel" <devel@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@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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. 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@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com>, "devel" <devel@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@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Sun, Apr 17, 2016 at 9:49 PM, Martin Mucha <mmucha@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.
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@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com>, "devel" <devel@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@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
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@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
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
----- Original Message ----- the persisting 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Mon, Apr 18, 2016 at 12:10 PM, Roman Mohr <rmohr@redhat.com> wrote:
On Sun, Apr 17, 2016 at 9:49 PM, Martin Mucha <mmucha@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.
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@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com>, "devel" <devel@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@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
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@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
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
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
----- Original Message ----- the persisting the 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[6] https://projectlombok.org/features/Builder.html
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Hi, an update on the ovirt-engine application wide tests. When [6] is merged, everything is ready to use. Please have a look on the post here: http://rmohr.github.io/continuous%20integration/2016/07/04/application-scope... for a How-To and why it is implemented the way it is. Reply here or ping me anytime if you have questions or want some help. Happy testing :) Roman On Wed, Apr 13, 2016 at 3:22 PM, Roman Mohr <rmohr@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/
participants (5)
-
Eyal Edri -
Martin Mucha -
Roman Mohr -
Roy Golan -
Vojtech Szocs