Revisiting MapperIT Tests

Hey Elias,

Yes, this is a great idea. I was just trying to troubleshoot a *MapperIT test case and it was a pain to have to keep cleaning and re-seeding the db in order to run through the test case over and over.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Dec 15, 2015, at 12:29 PM, Elias Muluneh eliasmu@gmail.com wrote:

The Integration Tests in OpenLMIS heavily assume that the database is set up afresh and the seed scripts executed. To be specific, I am referring to *MapperIT tests, Integration Tests could in the future be written for anything that is not mapper too.

Historically, not all database objects had CRUD code that could be used to setup required reference data in code, easily for the integration tests. For example, to insert a product, one needs to have a dosage unit, since there were no mappers that can quickly be used to insert this, a part of the setup process went into the gradle seed task. Basically, the seed task was a lazy man’s approach to writing setup code for all mapper tests. Overtime however, many of these database objects got CRUD code that can be used in specific test setup process. Given this progress, I argue that we should consider ensuring that MapperIT tests can run without assuming the database to be fresh and seeded.

If the *MapperIT tests do not assume database state, they can actually be used to test if the code integrates well with existing data / database.

  • They can be executed on a the production database, or a staging database at the very least and be able to find problems.
  • They can be used to verify if the code is compatible with the schema or schema version. Currently, there is no verification in place except that we trust FlywayDb has done its job.
  • They can identify other unrelated issues with schema. Example: An External tool inserted data in a table but did not update the postgres sequence. In this scenario, any OpenLMIS code that inserts data to the same table will be failing.
  • gradle “seed” tasks can be combined with “testseed” and reduce the number of gradle tasks. (that is one less confusing task for new developer)
  • The gradle build task will become one step closer to being “gradle build” which is less cluttered compared to “gradle setupDb seed build” which is the minimum required gradle task. I can definitely live with “gradle build”
    Feedbacks and thoughts are appreciated!

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/fbaf0848-bc6a-4ee8-ae76-8b925d99cf86%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Thanks Chongsun,

That is also another case in point. It eats up a lot of developer time.

Regards

Elias

···

On Tuesday, December 15, 2015 at 4:31:13 PM UTC-5, Chongsun Ahn wrote:

Hey Elias,

Yes, this is a great idea. I was just trying to troubleshoot a *MapperIT test case and it was a pain to have to keep cleaning and re-seeding the db in order to run through the test case over and over.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Dec 15, 2015, at 12:29 PM, Elias Muluneh eli...@gmail.com wrote:

The Integration Tests in OpenLMIS heavily assume that the database is set up afresh and the seed scripts executed. To be specific, I am referring to *MapperIT tests, Integration Tests could in the future be written for anything that is not mapper too.

Historically, not all database objects had CRUD code that could be used to setup required reference data in code, easily for the integration tests. For example, to insert a product, one needs to have a dosage unit, since there were no mappers that can quickly be used to insert this, a part of the setup process went into the gradle seed task. Basically, the seed task was a lazy man’s approach to writing setup code for all mapper tests. Overtime however, many of these database objects got CRUD code that can be used in specific test setup process. Given this progress, I argue that we should consider ensuring that MapperIT tests can run without assuming the database to be fresh and seeded.

If the *MapperIT tests do not assume database state, they can actually be used to test if the code integrates well with existing data / database.

  • They can be executed on a the production database, or a staging database at the very least and be able to find problems.
  • They can be used to verify if the code is compatible with the schema or schema version. Currently, there is no verification in place except that we trust FlywayDb has done its job.
  • They can identify other unrelated issues with schema. Example: An External tool inserted data in a table but did not update the postgres sequence. In this scenario, any OpenLMIS code that inserts data to the same table will be failing.
  • gradle “seed” tasks can be combined with “testseed” and reduce the number of gradle tasks. (that is one less confusing task for new developer)
  • The gradle build task will become one step closer to being “gradle build” which is less cluttered compared to “gradle setupDb seed build” which is the minimum required gradle task. I can definitely live with “gradle build”
    Feedbacks and thoughts are appreciated!

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
openl...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/fbaf0848-bc6a-4ee8-ae76-8b925d99cf86%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.