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

Unit testing & review comments #3608

Merged
merged 9 commits into from
Feb 20, 2024

Conversation

dbutenhof
Copy link
Member

@dbutenhof dbutenhof commented Feb 5, 2024

PBENCH-1315

The index-map fix was submitted without unit tests so we can get it deployed to resolve the immediate PostgreSQL resource problems. This follow-on adds unit testing (and some late review comments).

PBENCH-1315

The index-map fix was submitted without unit tests so we can get it deployed
to resolve the immediate PostgreSQL resource problems. This follow-on adds
unit testing (and some late review comments).

__NOTE__: this isn't complete, but it's far easier to get a coverage report
from the CI than locally, so I'm posting a draft, which I'll be updating as
I build test cases.
@dbutenhof dbutenhof added Server Unit tests API Of and relating to application programming interfaces to services and functions labels Feb 5, 2024
@dbutenhof dbutenhof self-assigned this Feb 5, 2024
@dbutenhof
Copy link
Member Author

Ugh:

FileExistsError: [Errno 17] File exists: '/home/jenkins/.pquisby/'

@webbnh
Copy link
Member

webbnh commented Feb 5, 2024

Ugh:

FileExistsError: [Errno 17] File exists: '/home/jenkins/.pquisby/'

The good news is, that only happens on the first build....

This'll give some coverage of all three cases, but all based on the theory of
"call Elasticsearch which returns nothing", which isn't realistic. I'm just
experimenting with what I can twist out of the `Common` baseclass here, which
isn't really suited for this API but has enough flexibility (I think) to "make
do".
Still not ready for review: just checking coverage after more unit hacks.
I cleaned up some questionable "bad request" errors that aren't under user
control, allowing me to back out a query fixture hack.

Added two test cases for `_search` return error handling. There's one more
"non-mock" error case I can tease out, but not today.
This proved an "interesting" journey. I found several returns that don't really
make sense: for example, the old delete/update logic reported a `Sync.update`
failure as `CONFLICT` rather than `INTERNAL_SERVER_ERROR`. The fixture we use
install the Elasticsearch mock response and call the API needs to know whether
to install the mock: it has to be right as either installing the mock and not
calling it or calling it without the mock will result in failure. The current
logic around installation of the mock proved difficult to reconcile with the
need to handle `INTERNAL_SERVER_ERROR` both *before* and *after* the call to
Elasticsearch. As a result, I ended up massively refactoring the `query_api`
fixture code to simplify the logic based on a three-state override (neutral,
force, or suppress) in the new `expect_call` parameter.
Do we have 100% *now*??
I fixed up mocking to properly unit test the `GET`, and realized that in the
current simplistic form, the output wasn't very useful as it wouldn't capture
the Elasticsearch `_index` value. A more useful output for a general `GET
/datasets/<id>` would be a summary rather than returning full documents. So
I rewrote the code and adjusted the unit tests.

Incidentally, after the production server PostgreSQL recovery, I found that my
report generator was tripping over datasets which had no operational status: I
suspect this was due to some hole in intake (although I think that failure to
create the `UPLOAD` operational status should have failed the intake, I'm not
going to debug that today). I did, however, adjust the report generator to
detect and report this case gracefully instead of failing with an f-string
formatting error. I also added a summary line of rows, tables, and size for
the SQL report.
@dbutenhof dbutenhof marked this pull request as ready for review February 9, 2024 16:44
@dbutenhof dbutenhof requested a review from webbnh February 9, 2024 16:45
@dbutenhof
Copy link
Member Author

I could maybe throw in a few more mock cases but basically there are three realistically unreachable edge cases left uncovered and making them fire would be messier than I want to try to justify right now. We're at 97% line coverage and 95% conditional coverage, which is pretty good.

webbnh

This comment was marked as resolved.

dbutenhof

This comment was marked as resolved.

Copy link
Member

@webbnh webbnh left a comment

Choose a reason for hiding this comment

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

Sorry that you're suffering "bored time"...nice to see this finished, though! 😁

@dbutenhof
Copy link
Member Author

Sorry that you're suffering "bored time"...nice to see this finished, though! 😁

More like, I read your comments and my brain got locked into these PRs so the only way past was through ... 😆

@dbutenhof dbutenhof merged commit d6b8f26 into distributed-system-analysis:main Feb 20, 2024
4 checks passed
@dbutenhof dbutenhof deleted the deltest branch February 20, 2024 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Of and relating to application programming interfaces to services and functions Server Unit tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants