7am PST / 3pm CEST
Toll: +1-415-655-0001
Number: 199 948 686
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 | ||
??? |
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
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
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
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
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