2017-10-27 October learning session

Date

27 Oct 2017

Attendees

Goals

Watch learning material Advanced Unit Testing (https://app.pluralsight.com/library/courses/advanced-unit-testing/table-of-contents) - Test Utility Code
Discuss watched materials and compare to how things are handled in OpenLMIS - are there any ideas/patterns/workflows we can adopt in OpenLMIS?

Discussion

The material presented four patterns and demos on what problems the pattern can solve and how to refactor the existing code to use the pattern. Out of those four, we have chosen three to watch and discuss:

Object Mother / Fluent Builder
SUT Mother / SUT Builder
Fixture Object

Is this something that we had problems with / can be useful in OpenLMIS?

This has been a problem in OpenLMIS - we have a lot of private methods that create test objects per test class
We have reviewed and discussed https://github.com/OpenLMIS/openlmis-referencedata/blob/8b90eee53038d401f82e14e520010e6c66d33546/src/integration-test/java/org/openlmis/referencedata/web/FacilityControllerIntegrationTest.java#L801 as an example
The code in private methods is not reusable outside of the test class, therefore each new test class must introduce/build the test object on its own
Having to create test objects per test class is time consuming. Test classes could reuse the test objects in many cases and speed up writing tests

Could this pattern be applied to UI tests as well / is this also a problem in UI tests?

Yes - there's a lot of code duplication both with test objects and mocking the same behaviour in multiple places
Usually the objects created are not very representative - they only contain one or two properties set (eg. "id" and "code") which are necessary for the given test; it would be better if those were complete objects and Fluent Builder could help with it

How to best approach introducing the pattern in OpenLMIS?

Refactoring all the test classes at once / in a single ticket is probably not achievable
Do it as we go - instead of introducing a new test object in a private method - create a suitable builder per Fluent Builder pattern
Make sure we enforce that in code reviews - also update the code review checklist
Have a proof of concept - at least one implementation of the Fluent Builder pattern to have an example to follow

How about Fixture objects?

Not a big issue currently, since this is something that solves problems integrating multiple SUT Builders and Fluent Builders
Set up for the tests done in methods annotated @Before - common setup in base, abstract classes
Could be useful if we decide to introduce fluent builders and SUT builders
Could help by having a single place to set up for both unit and integration testing and possibly reuse some of the test objects

Wrap up

We have asked every participant to give a score on how useful this meeting was and how helpful this specific material was. The voting was anonymous and each participant could give a score from 1 (useless) to 10 (very useful).
The averages were:

How useful are those meetings: 8/10
How useful was this specific material? (Unit Testing - Test Utility Code): 6.75/10

Final thoughts

Let's make sure we follow up on watched materials and discuss introducing the patterns in OpenLMIS
It wasn't something that was quite new or surprising - but it's still something that we miss in OpenLMIS
All examples were based on C#

Action items

Nikodem Graczewski to discuss introducing Fluent Builder / SUT Builder pattern on the UI
Mateusz Kwiatkowski to discuss introducing Fluent Builder / SUT Builder pattern on the backend
Nikodem Graczewski to update code review checklist after tech call
Sebastian Brudziński to respond to the e-mail and to schedule tech comittee topics/time