-
Notifications
You must be signed in to change notification settings - Fork 739
Adding functional tests for psycopg2 integration #528
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
Adding functional tests for psycopg2 integration #528
Conversation
Codecov Report
@@ Coverage Diff @@
## master #528 +/- ##
==========================================
+ Coverage 88.97% 89.38% +0.41%
==========================================
Files 43 43
Lines 2213 2195 -18
Branches 248 250 +2
==========================================
- Hits 1969 1962 -7
+ Misses 173 161 -12
- Partials 71 72 +1
Continue to review full report at Codecov.
|
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.
Have a few comments about the error handling patterns and reducing them. Can you look through those? After we discuss I can change to approve: the code overall looks great.
cls._connection.close() | ||
|
||
@fixture(autouse=True) | ||
def connect_to_db(self): |
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.
it feels a little weird to me to have a mix of pytest fixtures, and of the standard setup/teardown unittest pattern.
Can we normalize to one or the other? I think given the current precedent on unittest-style, that would be preferable.
since it's autouse, I figure it can be added to the setup/teardown method.
Or, I'm ok with just moving the class level fixtures like cursor to pytest fixtures as well. @c24t for his thoughts, since he's been arguing against pytest fixtures in our codebase.
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.
def connect_to_db(self): | ||
if self._connection is None: | ||
# Try to connect to DB | ||
for i in range(5): |
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.
why do we need this retry logic? seems like even if we need it, 5 retries is a lot of times.
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.
DB will take sometime to startup in docker, maybe having less retries and more wait time?, it could take like 15 or 20 seconds to be ready to receive connections
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.
Another option is to fail immediately in the tests and replace docker-compose -up
with a script that does the same and blocks until the container can accept connections. If possible I think it's a good idea to avoid sleeping at all in tests, and between this and #526 we're looking at adding up to a minute of idle time to an already-slow test suite.
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.
Added a python script to check DB connections, so tests will not have any sleep but there will be initial script check for all tests, this will improve waiting if something goes wrong with docker setup and test will fail quickly
ext/opentelemetry-ext-docker-tests/tests/postgres/test_psycopg_functional.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-ext-docker-tests/tests/postgres/test_psycopg_functional.py
Outdated
Show resolved
Hide resolved
with self._tracer.start_as_current_span("rootSpan"): | ||
try: | ||
self._cursor.callproc("test", ()) | ||
except Exception as err: |
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.
does this exception need to be caught? seems like it's fine to let it raise up.
Even if it's unrelated to our code, exceptions are a separate code path that we should exercise explicitly.
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.
Stored procedure doesn't exist so callproc will fail but Span will be created, I want to avoid as much pre setup as possible for this tests
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.
You might want an assertRaises
here instead then, the tests generally shouldn't print anything.
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.
Similar comments to #526. I've got reservations about the autouse fixture and sleeping/retrying in unit tests, but we can address that in another PR. The only blocking comment here is about the printed exception.
with self._tracer.start_as_current_span("rootSpan"): | ||
try: | ||
self._cursor.callproc("test", ()) | ||
except Exception as err: |
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.
You might want an assertRaises
here instead then, the tests generally shouldn't print anything.
def connect_to_db(self): | ||
if self._connection is None: | ||
# Try to connect to DB | ||
for i in range(5): |
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.
Another option is to fail immediately in the tests and replace docker-compose -up
with a script that does the same and blocks until the container can accept connections. If possible I think it's a good idea to avoid sleeping at all in tests, and between this and #526 we're looking at adding up to a minute of idle time to an already-slow test suite.
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.
Thanks for refactoring out the pytest! (Although I personally would love full pytest).
I still think there's some improvement in the connectivity checks that should be addressed, or else it'll provide incomplete information to others if it fails. Once that's fixed up I'll switch to approved.
Thanks for focusing on this!
def check_docker_services_availability(): | ||
try: | ||
print("Checking Postgres availability") | ||
check_postgres_connection() |
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.
should mongo availability also be checked?
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.
MongoDB have been super fast to be available, will add the logic just to be safe in case this changes.
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.
Thanks for addressing all the feedback @hectorhdzg, no more blocking comments from me.
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.
LGTM, thanks for addressing that!
E2E verification for span creation using psycopg2 and dbapi integrations