Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(Schedules): Fix alerts not showing up for stops with inbound trains #2029

Merged
merged 4 commits into from
May 9, 2024

Conversation

kotva006
Copy link
Contributor

@kotva006 kotva006 commented May 3, 2024

Summary of changes

This fixes the start point of a shuttle disruption from showing predictions and showing the effect title instead

https://app.asana.com/0/home/1201123880594717/1206362494901588


General checks

  • Are the changes organized into self-contained commits with descriptive and well-formatted commit messages? This is a good practice that can facilitate easier reviews.
  • Testing. Do the changes include relevant passing updates to tests? This includes updating screenshots. Preferably tests are run locally to verify that there are no test failures created by these changes, before opening a PR.
  • Tech debt. Have you checked for tech debt you can address in the area you're working in? This can be a good time to address small issues, or create Asana tickets for larger issues.

New UI, or substantial UI changes

  • Cross-browser compatibility is less of an issue now that we're no longer supporting IE, but changes still need to work as expected in Safari, Chrome, and Firefox.
  • Are interactive elements accessible? This includes at minimum having relevant keyboard interactions and visible focus, but can also include verification with screen reader testing.
  • Other accessibility checks such as sufficient color constrast, or whether the layout holds up at 200% zoom level.

New endpoints, or non-trivial changes to current endpoints

  • Have we load-tested any new pages or internal API endpoints that will receive significant traffic? See load testing docs
  • If this change involves routes, does it work correctly with pertinent "unusual" routes such as the combined Green Line, Silver Line, Foxboro commuter rail, and single-direction bus routes like the 170?

@kotva006 kotva006 requested a review from a team as a code owner May 3, 2024 16:38
@kotva006 kotva006 requested a review from anthonyshull May 3, 2024 16:38
|> load_from_other_repos
end

def all_no_cache(opts) when is_list(opts) and opts != [] do
opts
|> add_all_optional_params()
|> fetch()
|> filter_predictions(nil)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of passing nil here you can just make it a default argument.

@@ -2,6 +2,7 @@ defmodule Predictions.RepoTest do
use ExUnit.Case, async: false
@moduletag :external

import Mock
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are removing Mock and replacing it with Mox. So, we shouldn't be adding new Mock instances to tests. We especially shouldn't use both in the same test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am aware, please see my comment in slack

@@ -58,6 +59,67 @@ defmodule Predictions.RepoTest do
end
end

test "filtes out predictions with no departure" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo

Comment on lines 71 to 110
%JsonApi.Item{
attributes: %{
"departure_time" => nil,
"arrival_time" => five_minutes_in_future_string,
"direction_id" => 1
},
relationships: %{
"route" => [
%{
id: "Red"
}
],
"trip" => [],
"vehicle" => [],
"stop" => [
%{id: "StopID"}
]
}
},
%JsonApi.Item{
attributes: %{
"departure_time" => five_minutes_in_future_string,
"arrival_time" => five_minutes_in_future_string,
"direction_id" => 1
},
relationships: %{
"route" => [
%{
id: "Red"
}
],
"trip" => [],
"vehicle" => [],
"stop" => [
%{id: "StopID"}
]
}
}
]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all of these attributes necessary for exercising the test? Would it work just setting the departure_time? These two structs are exactly the same except for that one attribute, so there should be a shorter and clearer way to communicate that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, all these fields are required. The parsing errors out if any of these fields are missing. Ideally I'd like to mock away some of that, but it seemed outside the scope of this fix.

{Stops.Repo, [:passthrough], get_parent: fn _ -> %Stops.Stop{id: "Parent"} end},
{Routes.Repo, [:passthrough], get: fn _ -> Routes.MockRepoApi.get("Red") end}
]) do
predictions = Repo.all(route: "39")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a magic string? What happens if we do Repo.all(route: "38")?

Copy link
Contributor Author

@kotva006 kotva006 May 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, its just a random number

Comment on lines 63 to 67
five_minutes_in_future = DateTime.add(Timex.now(), 5, :minute)

{:ok, five_minutes_in_future_string} =
Timex.format(five_minutes_in_future, "{ISO:Extended:Z}")

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you don't need the :ok and an error would just cause the test to fail you can do:

departure_time =
  Timex.now()
  |> DateTime.add(5, :minute)
  |> Timex.format!("{ISO:Extended:Z}")

@kotva006 kotva006 requested a review from anthonyshull May 7, 2024 13:14
Comment on lines 70 to 109
%JsonApi.Item{
attributes: %{
"departure_time" => nil,
"arrival_time" => five_minutes_in_future_string,
"direction_id" => 1
},
relationships: %{
"route" => [
%{
id: "Red"
}
],
"trip" => [],
"vehicle" => [],
"stop" => [
%{id: "StopID"}
]
}
},
%JsonApi.Item{
attributes: %{
"departure_time" => five_minutes_in_future_string,
"arrival_time" => five_minutes_in_future_string,
"direction_id" => 1
},
relationships: %{
"route" => [
%{
id: "Red"
}
],
"trip" => [],
"vehicle" => [],
"stop" => [
%{id: "StopID"}
]
}
}
]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two structs are exactly the same except for that one attribute, so there should be a shorter and clearer way to communicate that.

Because these two structs are identical except for one attribute, you could define it once and then override that attribute for the second. It will make the test shorter. That also helps to communicate the difference between the two.

Comment on lines 119 to 122
"type" => "1",
"long_name" => "Red Test Subway",
"direction_names" => ["North Test Name", "South Test Name"],
"direction_destinations" => ["North Test", "South Test"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are all magic strings. As per the testing doc we all reviewed and agreed to, we should be using Faker for these (and all others in this file).

https://www.notion.so/mbta-downtown-crossing/The-Four-Legs-of-Quality-Programming-b35248799da84e02b93887361d5bf343

@@ -58,6 +58,102 @@ defmodule Predictions.RepoTest do
end
end

test "filtes out predictions with no departure" do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This typo is still here.

|> load_from_other_repos
end

def all_no_cache(opts) when is_list(opts) and opts != [] do
opts
|> add_all_optional_params()
|> fetch()
|> filter_predictions(nil)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a default argument of nil rather than passing in nil makes both the function definition and it's application much clearer and cleaner.

@anthonyshull
Copy link
Contributor

If we're going to have this test in there then we should remove the external moduletag and make sure the test runs. You can add an external tag to individual tests.

@kotva006 kotva006 requested a review from anthonyshull May 8, 2024 17:04
Copy link
Contributor

@anthonyshull anthonyshull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥂

@kotva006 kotva006 merged commit a6f50a0 into main May 9, 2024
24 checks passed
@kotva006 kotva006 deleted the rk/rl-shuttle branch May 9, 2024 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants