-
-
Notifications
You must be signed in to change notification settings - Fork 724
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
Improves test coverage on Orders and Distributors report #12790
Improves test coverage on Orders and Distributors report #12790
Conversation
37c3368
to
33642c0
Compare
0d28666
to
20daddc
Compare
31bfc6e
to
b7ab594
Compare
I'm a bit surprised about the failing test here. We have something very similar (actually, the same code) on I suspect this might related to the fact that hitting the "Download report" opens a new window on the browser, rather than downloading the file to the local system... |
d75690e
to
634a7d6
Compare
Ok, so at least there is some coherence now: both tests on PDFs fail. For some reason, this test has started to fail consistently. I'll remove the PDF assertion on it as well, as it is failing locally as well:
|
39911b3
to
67c0ccd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work!
I still think that we should move the data tests out of the system specs and have only one smoke test per report in system specs.
Spree::LineItem.where( | ||
order_id: ready_to_ship_order1.id # Total rows should equal nr. of line items, per order | ||
).count |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it would be more robust to replace this with the literal number.
visit admin_reports_path | ||
click_link "Orders And Distributors" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is loading two pages when we need only the last one. It's good to go through the journey from reports path clicking on the report once, to proof that you can get to the report that way. But here you are doing it for several examples when you could visit the report directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point 👌
rows = find("table.report__table").all("thead tr") | ||
table_headers = rows.map { |r| r.all("th").map { |c| c.text.strip } } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a helper for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum, true this is used throughout report specs, although with slight variations. Would be great to unify this in a helper.
it_behaves_like "reports generated as", "CSV", "csv" | ||
it_behaves_like "reports generated as", "Spreadsheet", "xlsx" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it be that, depending on the version of Chrome, the PDF is opened in the browser instead of downloaded? That would explain the error, seeing a timeout because the file is never saved, only displayed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PDF is opened in the browser instead of downloaded
I'm positive, that this is indeed the case - I've verified this in headless=false mode. But I have not found a way to download the file...
Ok, I did not realize that you literally meant only one smoke test 😅 I'll keep this in mind for the upcoming specs. In the meantime, I'll mode this back to In Progress to address your comments. Thanks! |
80172db
to
50da07b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I think there's a couple of things we could improve before merging.
As an aside: I agree with Maikel that testing data can be done in unit tests which would be more efficient, not to mention easier. Based on your experience with coding now, would you be interested to try that next time? I'd be happy to give some pointers.
Here's the first random example I can find, which shows how the parameters are specified, and the results are checked: https://github.com/openfoodfoundation/openfoodnetwork/blob/master/spec/lib/reports/bulk_coop_report_spec.rb#L62
# for one distributor | ||
select2_select distributor.name, from: "q_distributor_id_in" | ||
run_report | ||
expect(page).to have_content(distributor.name), count: 15 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem to be checking that the other distributor was filtered out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome... Very sharp eye 🔍 The count:
argument must within the brackets - if we use brackets at all! I've learned this yesterday the hard way, this was not very obvious to me. Thank for pointing it out.
rows = find("table.report__table").all("tbody tr") | ||
table = rows.map { |r| r.all("td").map { |c| c.text.strip } } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we can remove this as it's now in the helper method.
rows = find("table.report__table").all("tbody tr") | |
table = rows.map { |r| r.all("td").map { |c| c.text.strip } } |
3b26de0
to
76ad152
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me, but I have a question about the new pending spec:
xit "aggregates results per variant" do | ||
pending '#9678' | ||
expect(all('table.report__table tbody tr').count).to eq(4) | ||
# 1 row per variant = 2 rows | ||
# 2 TOTAL rows | ||
# 4 rows total | ||
|
||
expect(table_headers[0]).to eq( | ||
["Supplier Name", "Baked Beans", "1g Small, S", | ||
"Distributor Name", "7", "10.0", "70.0", "UPS Ground"] | ||
) | ||
expect(table_headers[1]).to eq( | ||
["", "", "", "TOTAL", "7", "", "70.0", ""] | ||
) | ||
expect(table_headers[2]).to eq( | ||
["Supplier Name", "Baked Beans", "1g Big, S", | ||
"Distributor Name", | ||
"3", "10.0", "30.0", "UPS Ground"] | ||
) | ||
expect(table_headers[3]).to eq(["", "", "", "TOTAL", "3", "", "30.0", ""]) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct? Issue #9678 is closed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes indeed - thanks @dacook. Inconsistent results ordering is now fixed and the spec is now updated.
Sets up an enterprise user instead of an admin user
Moves file download into report helper Removes pdf file assertation Removes test on PDF file on sales tax report Removes PDF testing from helper
This spec was appearently flaky, let's see if this change stabilizes it. It came up here: https://github.com/openfoodfoundation/openfoodnetwork/actions/runs/10639846576/job/29498582671?pr=12790 Removes CSV tests based on permissions Not sure we need these tests, proposing to remove them and use shared examples to test file download
into its helper, which touches other system specs (namely orders_and_fulfillment_spec.rb). Rubocop fixup
The datet-time-picker test case was failing for me locally, but passing on GH-Actions. Controlling the time should prevent this type of flakyness
The pending was not signalling the bug fix as ordering needed to be corrected
67a3145
to
556539d
Compare
Failing spec is this one here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a couple of suggestions but they are only a nice-to-have. I'm much more looking forward to seeing the unit tests. 😉
def table_headers | ||
rows = find("table.report__table").all("thead tr") | ||
rows.map { |r| r.all("th").map { |c| c.text.strip } } | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Be aware that this method name is in the global scope in specs. If another part of the specs wanted to read the table headers of a different table then someone may define a method with the same name and there would be a collision. It would be better to name this report_table_headers
.
Also, do you need the find
?
def table_headers | |
rows = find("table.report__table").all("thead tr") | |
rows.map { |r| r.all("th").map { |c| c.text.strip } } | |
end | |
def report_table_headers | |
rows = all("table.report__table thead tr") | |
rows.map { |r| r.all("th").map { |c| c.text.strip } } | |
end |
around do |example| | ||
Timecop.travel(completed_at) { example.run } | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not freezing time. It's just going to the beginning of the second, I guess. Therefore flakiness is less likely but not impossible.
Sets up an enterprise user instead of an admin user
What? Why?
Focuses on having a simple, dedicated system spec for Orders and Distributors report:
It moves helper methods into its dedicated file, which affects other reports, so some changes were done there as well.
What should we test?
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Documentation updates