Forecast Fixture Revamp

spec.md

Automatically Cultivate Atomic Fixtures

The main idea is to have a Rake/NPM task that, for each specified endpoint, finds the index.json fixture and creates the individual, id-based fixtures as well as filtered response fixtures under the /filtered/ directory. The filters are on pre-defined properties (like FK, start/end dates, etc. See below for details).

All files created by the task(s) are from now on ignored in .gitignore.

Adding and updating fixtures will only require changes to index.json, no more copy/paste, no long diffs of the same changes in PRs, no more discrepancies stemming from wrong/missed updates. By extension, this will make code review easier and thus may also easier catch issues with udpates only being performed on one—but not all dependant—fixtures (like changing a date across all fixtures that include a project).

As part of the test setup for both, FS and FC, the rake task is run after initializing and updating the FF submodule to cultivate all atomic and filtered fixtures before executing any tests. This will allow it to work even in CI just fine!

Concerns

The one obvious concern is the increased number of files, especially of filters. Right now, we have only created fixtures to cover the cases we needed to test for, like start/end filters for the viewports the client ever queries for that have assignments, or only the ID-based fixtures we’d ever request individually. With this task, all objects in the index.json are set up with their atomic version, which means more files. Since they are all ignored and only exist locally, I don’t necessarily see this as a problem. After all, the reason we never created those (untested) fixtures was the overhead in maintenance which this approach will mitigate to 100%.

Structure and Conditions

Below is a quick overview of changes to the current fixture structure, along with the filter properties and conditions. The top-level lists are not including any of the custom update.json fixtures (for example), as we can’t generate those of course. Instead, it only focues on the ones we can spawn from the fire hose fixtures of each endpoint.

/aggregate

/future_scheduled_hours

Move project_1.json etc to /filtered/

/remaining_budgeted_hours

Move project_5.json etc to /filtered/

/assignments

index.json

• ids
• /filtered/index-start_date-YYYY-MM-DD-end_date-YYYY-MM-DD (3 week increments, for all spanned timeframes defined in index.json
• /filtered/index-project-PROJECT_ID
• /filtered/index-person-PERSON_ID

Update server to use /filtered/ instead of custom index_start_and_end_date_filtered.json and index_person_filtered.json

/clients

index.json

• show
• /filtered/index-state-active
• /filtered/index-state-archived

/milestones

index.json

• show
• /filtered/index-start_date-YYYY-MM-DD-end_date-YYYY-MM-DD (3 week increments, for all spanned timeframes defined in index.json)
• /filtered/index-project-PROJECT_ID

Update server to use /filtered/ instead of custom index_start_and_end_date_filtered.json

/people

index.json

• show
• /filtered/index-state-active.json
• /filtered/index-state-archived.json

/projects

index.json

• show

Add /filtered/ for active/archived Q: Do we need 1-updated-dates-1.json etc?

/teams

index.json

• show.json

/user_connections

Move index_limit_filtered.json to /filtered/