2017-11-02 Meeting notes
Date
7am PST / 3pm CEST
Meeting Link
Toll: +1-415-655-0001
Number: 199 948 686
Attendees
Goals
- Better code and testing patterns
- Non-functional requirements - results on progress from recent performance push
- Fluent builder pattern review
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
Fluent Builder / SUT Builder pattern on the backend | Mateusz Kwiatkowski | ||
Fluent Builder / SUT Builder pattern on the UI | Nikodem Graczewski (Unlicensed) | ||
A quick look at the Exporter pattern and Select N+1 | Josh Zamor and Paweł Albecki (Deactivated) | ||
Action Item review from last time | Josh Zamor | ||
Non-functional requirement progress - performance? | Josh Zamor | ||
??? |
Notes
Fluent Builder
Lets us build test data for unit tests
makes creation fast with less effort
Allows us to make a Builder class, that when calling the build method it creates an object with no content
Example:
A requisition object gets built with default settings and objects
We would be adding "cast on" methods that are descriptive
This allows us to call a single method when we need an invalid requisition
The builder would take care of the facility creation → and so on
This would let us get rid of code duplication
Would make tests more descriptive
Fluent Builder in Services
There is about 100 lines of code that just creates the test data
The fluent builder pattern would help us get rid of the extra code
This lets us get to the code we want to test quickly
Generally we omit all the data that we don't need to know explicitly
The number of "with" methods will increase, and we want to avoid painful maintenance in our unit tests
Discussion
How will we maintain thse?
Right now we have a package in the testing code, we might need to just take a stab at making a change
Does this speed up execution? No - but it speeds up creating unit tests
How is this different than DemoData?
Would these be used in the integration tests?
Yes, right now they are just in the unit tests - but they would make sense there too
How do we save them to the repository after they have been built? What if we make a builder that isn't actually savable to the database? How flexible are they if we need to change different values?
→ We are concerned about how saving the data actually works
Fixtures
We could make sure the build object is savable if we focus on making fixtures
Fluent Builder in UI
Can we use the builder in the UI testing
Objects in UI tests are not really representation - they are small minimal objects - which don't match the current items
In real case we would be extending the pageBuilder
Add the file as a .spec file so that it isn't reused
This would make an object that is representative about how pieces of functionality would work.
Using builders would force us to use more object classes within the UI
→ currently the builder pattern might not help most existing code
We could easily introduce this pattern to testing
This builder would reside in the reference data facility – and we wouldn't have to duplicate into other dependent modules
Implementing Fluent Builder
Start using building pattern in new code
Find smaller tickets to try implementing and share back to technical committee
How/Where we document these builders in reviews documentation is something we will need to think about
N+1 Select Pattern
Goal to avoid N+1 patterns - our DTO builds being slow is a result of something like this
Example which was from OLMIS-3351
Benefits
- Domain object when doing export, it doesn't need to worry about DTOs → exporter just puts items into the interface
- DTOs don't need to get the information that they don't actually need to export
- Performance benefit, we don't have to pull things from the database that we don't need
- Example: Requisition status changes
- Some DTO would implement a requisition line item exporter – but the DTOs that don't need it would just leave it optional
- We don't need to write additional methods for the domain class
Action Items
- Find simple Service ticket to add fluent builder pattern (After 3.2.1 release)
- Find simple UI ticket to add fluent builder pattern (After 3.2.1 release)
- Josh Zamor Document fluent builder pattern in developer documents
OpenLMIS: the global initiative for powerful LMIS software