cleanup: Add more alert factories for use in SystemStatus.SubwayTests #2347
Conversation
joshlarson
force-pushed
the
jdl/system-status-alert-factory
branch
from
5d53205 to
f852999
Compare
| def for_route(alert, route_id) do | ||
| %{ | ||
| alert | ||
| | informed_entity: | ||
| InformedEntitySet.build(:informed_entity_set, | ||
| route: route_id, | ||
| entities: [ | ||
| InformedEntity.build(:informed_entity, route: route_id) | ||
| ] | ||
| ) | ||
| } | ||
| end | ||
|
|
There was a problem hiding this comment.
suggestion: If you adjust this function to be its own factory, you wouldn't need to create an alert and pass it to for_route/2. Say you want to call build(:alert_with_route, %{route_id: "Blue"}), that could work with something like this....
def alert_with_route_factory(%{route_id: route_id} = attrs) do
informed_entity = InformedEntitySet.build(:informed_entity_set,
route: route_id,
entities: InformedEntity.build_list(1, :informed_entity, route: route_id)
)
build(:alert, informed_entity: informed_entity)
end
| def with_high_priority_effect(alert) do | ||
| %{alert | effect: Faker.Util.pick(@high_priority_effects)} | ||
| end |
There was a problem hiding this comment.
Similarly, this could be
def high_priority_alert_factory do
build(:alert, effect: Faker.Util.pick(@high_priority_effects))
endto enable high_priority_alerts = build_list(4, :high_priority_alert)
There was a problem hiding this comment.
This comment and this one kind of go together to show why I didn't do it that way though, because I wanted to be able to chain them together, like 👇
build(:alert, effect: effect) |> active_during(time) |> for_route(affected_route_id)There was a problem hiding this comment.
It'd save you a chain or two, e.g. build(:alert_for_route, route_id: affected_route_id) |> active_during(time). But if you like each property being a separate step in the chain that's a choice.... but if you're doing the same steps over and over it might be more useful to make a factory tailored to that use case.
There was a problem hiding this comment.
Yeah that's fair - I guess I wasn't sure where to draw the line between what should be chained and what should be "top-level".
I was loosely following this
| alias Test.Support.Factories.Alerts.InformedEntitySet | ||
|
|
||
| @high_priority_effects [:delay, :shuttle, :station_closure, :suspension] |
There was a problem hiding this comment.
It'd be nice to not have to duplicate this from its source of truth.
There was a problem hiding this comment.
Yeah.... What IS its source of truth?
Also I just realized this point might be moot, since SystemStatus.Subway.subway_status/2 doesn't actually do anything with the effect now. 🤔
There was a problem hiding this comment.
Wait, what is giving the subway status feature the "high priority" alerts then?? 😅
There was a problem hiding this comment.
In alerts.ex, the filter_relevant/1 function ensures that only certain alerts are returned, and which effects are "relevant" is defined here.
In this PR, the results from alerts.ex are passed into subway_status/2.
That's how it works now - I'm not overly attached to that thought - there's probably a better way.
Follow-up to: