2017-11-02 Meeting notes

Date

02 Nov 2017

7am PST / 3pm CEST

Meeting Link

https://meetings.webex.com/collabs/#/meetings/detail?uuid=M0UUCAJ68OYLPMKAROOE9PJSBW-3O29&rnd=897752.12165

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

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

Example

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

Example

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