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 finish_job bug, add tests #328

Merged
merged 4 commits into from
Mar 10, 2021
Merged

Fix finish_job bug, add tests #328

merged 4 commits into from
Mar 10, 2021

Conversation

MrCreosote
Copy link
Member

Description of PR purpose/changes

EE2status attempting to access get_catalog_utils().catalog caused
finish_job() to throw an exception and consequently the job runner to freak out:

kbase/JobRunner#43

Accessed the catalog directly and added a unit test that covers the code
in question.

Also reduced the EE2Status API by making a method that was only used in tests "private".

Jira Ticket / Github Issue

  • [n/a] Added the Jira Ticket to the title of the PR e.g. (DATAUP-69 Adds a PR template)

Testing Instructions

  • Details for how to test the PR:
  • Tests pass in Github Actions and locally
  • Changes available by spinning up a local test suite

Dev Checklist:

  • My code follows the guidelines at https://sites.google.com/truss.works/kbasetruss/development
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • [n/a] I have made corresponding changes to the documentation
  • [?] My changes generate no new warnings - 3k warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • [n/a] Any dependent changes have been merged and published in downstream modules
  • I have run Black and Flake8 on changed Python Code manually or with git precommit (and the Github Actions build passes)

Updating Version and Release Notes (if applicable)

Method was unused outside the class other than in a test where it was
mocked out
EE2status attempting to access get_catalog_utils().catalog caused
finish_job() to throw an exception and consequently the job runner to freak out:

kbase/JobRunner#43

Accessed the catalog directly and added a unit test that covers the code
in question.
job_id=job_id, requested_job_perm=JobPermissions.WRITE, as_admin=False
),
call(
job_id=job_id, requested_job_perm=JobPermissions.WRITE, as_admin=False
Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks black this is so much better

Copy link
Member

@briehl briehl left a comment

Choose a reason for hiding this comment

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

Code changes look fine, but some failure tests might be helpful.

"job_id": job_id,
}
)
mongo.update_job_resources.assert_called_once_with(job_id, resources)
Copy link
Member

Choose a reason for hiding this comment

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

What about some negative tests? Or tests where failures are expected with bad inputs?

Copy link
Member Author

Choose a reason for hiding this comment

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

The point of this PR was not to add tests, per se - it was to fix the bug re accessing the catalog client by an instance variable that doesn't exist, and write tests that cover that bug so that it can't reoccur. The happy path test was enough to cover the bug, so failure tests weren't needed.

Copy link
Member

Choose a reason for hiding this comment

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

Testing the rest of that function would catch other issues before they happen and prevent other bugs from appearing.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, but that's true for lots of places in the code. The point of this PR is to fix and test a specific bug, not to add tests in general.

Copy link
Member

Choose a reason for hiding this comment

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

The point is to fix a bug and, hopefully, prevent others from taking its place due to poorly tested code. Please write some more tests to capture other failure conditions.

Copy link
Member Author

Choose a reason for hiding this comment

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

and, hopefully, prevent others from taking its place due to poorly tested code

Hmm, looks like we're at an impasse, because AFAIC, that is not part of the point of this PR. I'll bug @sychan to be a tiebreaker here.

Copy link
Member

Choose a reason for hiding this comment

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

Works for me. The past few times you complained of errors happening from untested code and from things that reviewers didn't catch, I figured this would be an opportunity to avoid that. Letting @sychan decide whether more work is warranted here is fine.

Copy link
Member Author

Choose a reason for hiding this comment

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

The past few times you complained of errors happening from untested code and from things that reviewers [note: and I, and 5 linters -g] didn't catch

That's still a valid complaint, and I'll continue to address it by adding tests for code that I touch. It's just that

  1. if I add unit tests for every piece of code I see that doesn't have unit tests I'll never work on the actual feature I'm supposed to be working on, and
  2. I want to keep this PR focused on the bugfix.

It became clear to me early on that unless I restrict adding tests to code I actually make changes to I won't finish, as demonstrated by the fact that I'm already several weeks into this process and just barely started on the feature.

Copy link
Contributor

Choose a reason for hiding this comment

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

Bill is correct on the need for testing failed runs, and given how important EE2 to the core functioning of our platform - we do, desperately, need more pervasive testing on the EE2 codebase. And it is ironic that Gavin is the one arguing for not adding tests, the shoe isn't so comfortable when its on the other foot!

The mitigating circumstance is that we are weeks (if not coming up months behind) on getting basic features implemented and we're 3 weeks from the end of the quarter, after which we are likely to take a huge hit on resourcing for the Bulk Import work, and I would actually like Gavin to go somewhat wide on the EE2 codebase, instead of deep at this point. I'm going to say we let this slide, and have Gavin move on - with the understanding that Gavin will work on incrementally improving the code coverage in EE2 as he does future PRs.

@sychan sychan merged commit 38254b1 into develop Mar 10, 2021
@MrCreosote
Copy link
Member Author

And it is ironic that Gavin is the one arguing for not adding tests, the shoe isn't so comfortable when its on the other foot!

While it's true I often ask for more tests in PR reviews, I don't think I've ever asked for tests for code that was not added or modified by the PR.

@MrCreosote MrCreosote deleted the dev-fix-status branch March 10, 2021 18:55
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.

3 participants