Fix broken tests #1683
No reviewers
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-17#1683
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "teardown-test1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
BITMESSAGE_HOME
doesn't always work, so we wrote a function to do thislogger
andBMConfigParser
now clear old config when loading newtest_logger
TestProcess
startOoogh, it looks sick ):
Sad. I didn't planned to bound the tests to travis.
Why shebang here?
This looks like a cheat.
TestProcessProto
does the same: https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/tests/test_process.py#L73I don't think that increasing timeouts gonna help.
core tests was designed to run from appdata. Maybe it's better to cleanup files.
Another helper ):
_translate ?
https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/bitmessageqt/support.py#L33
I cannot find where it's used
Oh, it's from unittest.TestCase. Got it.
If this hunk is platform dependent, maybe here should be some condition?
At your discretion
See more: https://travis-ci.org/github/g1itch/PyBitmessage/builds/738338172
I'm waiting.
I agree but I don't think it can be fixed without a lot of refactoring.
Ok.
I mean, I agree about the shebang, but the addressbook code shouldn't be in the UI like it is now. What other options are there? Not another thread to deal with addressbook?
Yes it's so that we have more info about the failures.
I haven't tested it on Windows, but I assumed the result will be empty. Maybe it can be wrapped in try/except. The output is only used if there is an assertion error, it's not an assertion itself.
TestProcessProto
first calls_stop_process
to send aSIGTERM
. This expects the program to already have closed on its own, and just sendSIGKILL
in an emergency.TimeoutExpired
andNoSuchProcess
if you want the tests to be more strict.TimeoutExpired
means that there is something very wrong as it's blocking aSIGKILL
.SIGKILL
, which I think lead unpredictably to problems.Maybe yes, but noone is going to do that.
Noone is working on a proper fix and other work can't be done until the tests succeed.
test_config_defaults
isn't waiting for the process to finish.ok
I did it in one of my rebased branches. It did not help, because cleanup is the least part of the problem.
I don't remember any shutdown tests failing in your test environment or current xenial travis setup.
TestAPIShutdown
failed on windows and on my recent fedora31 container.Windows failed until this run: https://travis-ci.org/github/g1itch/PyBitmessage/jobs/736655954
@ -27,3 +48,4 @@
]
_files = (
'keys.dat', 'debug.log', 'messages.dat', 'knownnodes.dat',
'.api_started', 'unittest.lock'
https://travis-ci.org/github/g1itch/PyBitmessage/jobs/738338187
I agree that it's cool to have all CRUD tasks (on messages, addressbook and black/white lists) in the main package to use them in
api
,bitmessageqt
and any other frontend. Also I was working on the single helper with all SQL queries in #1534 because it is bad to have SQL scattered among the code. It needs heavy testing. Currently it breaksbitmessageqt
because I missed some type cast or check.But hey, you need this helper now only because of
BITMESSAGE_HOME
in env and the absence of cleanup.Another thread is the last thing I would suggest. But recently I thought about using multiprocessing for test cases which use potentially dangerous imports.
Did you try this?
I can put the timeouts back, maybe some other changes that I made fixed the issues.
Looks like pyelliptic pointers.
@ -27,3 +48,4 @@
]
_files = (
'keys.dat', 'debug.log', 'messages.dat', 'knownnodes.dat',
'.api_started', 'unittest.lock'
That can be fixed later. We don't have a working OSX at the moment anyway.
ok let me try
@g1itch I refactored the use of
state.appdata
and removed the environment variable from.travis.yml
. It now passes buildbot's bionic and xenial, as well as xenial on travis-ci.org. Can you try rebasing your changes on top of it again?OK, I get it:
Wow! It looks like you really fixed the major issue with appdata while I was on a half way retracing it from debug -> helper_startap <-> state (loadConfig).
I do the opposite: I merge it to cleaned out ci branch: https://travis-ci.org/github/g1itch/PyBitmessage/builds/738506280
Whichever you prefer.
Some formatting options and two errors on windows I found.
@ -45,6 +45,7 @@ class TestProcessConfig(TestProcessProto):
def test_config_defaults(self):
"""Test settings in the generated config"""
self._stop_process()
self._kill_process()
This is like
tearDown()
without cleaning the files.Maybe
self.fail()
here?@ -99,0 +170,4 @@
self.assertLessEqual(
running_threads,
self._threads_count_max,
AttributeError on windows: https://travis-ci.org/github/g1itch/PyBitmessage/jobs/738506283
https://travis-ci.org/github/g1itch/PyBitmessage/jobs/738510444
That blindsig tests failed because of openssl-1.0.1 dll. If I install PyQt4 like in
winbuild.sh
it will fix the tests, because pyelliptic loads openssl-1.0.1 dll bundled with pyqt in that case.@ -99,0 +170,4 @@
self.assertLessEqual(
running_threads,
self._threads_count_max,
ok
ok, it can be split later in case you want to handle them differently
same as above
ok
@ -99,0 +139,4 @@
# because of https://github.com/giampaolo/psutil/issues/613
thread_names = subprocess.check_output([
"ps", "-L", "-o", "comm=", "--pid",
str(self.process.pid)
AccessDenied
on osx: https://travis-ci.org/github/g1itch/PyBitmessage/jobs/738524694@g1itch Thanks for the feedback so far, I'll fix those issues.
_kill_process
is a class method so you'd have to usecls.fail()
and I don't think that would work correctly. The documentation doesn't say what happens if there are exceptions intearDownClass
, only intearDown
. Looking at unittest source, it looks like an exception intearDownClass
also adds a new error entry in the totals, just liketearDown
is supposed to. So I think a more traditional exception likeOSError
is a better choice here. Perhaps an even better choice is to simply delete thisexcept
and let thepsutil.TimeoutExpired
propagate up.@ -45,6 +45,7 @@ class TestProcessConfig(TestProcessProto):
def test_config_defaults(self):
"""Test settings in the generated config"""
self._stop_process()
self._kill_process()
Yes I think you're correct.
@ -99,0 +170,4 @@
self.assertLessEqual(
running_threads,
self._threads_count_max,
Added an exception handler.
Done
done
@ -99,0 +139,4 @@
# because of https://github.com/giampaolo/psutil/issues/613
thread_names = subprocess.check_output([
"ps", "-L", "-o", "comm=", "--pid",
str(self.process.pid)
Test is now skipped on OSX.
Non-linux issues may be fixed later
It only seems to work on linux: https://travis-ci.org/github/g1itch/PyBitmessage/builds/738596816
Maybe also break on OSError?
@ -99,0 +140,4 @@
thread_names = subprocess.check_output([
"ps", "-L", "-o", "comm=", "--pid",
str(self.process.pid)
]).split()
Maybe this can be shortened now:
Not so easy: https://travis-ci.org/github/g1itch/PyBitmessage/builds/738699572
@ -99,0 +140,4 @@
thread_names = subprocess.check_output([
"ps", "-L", "-o", "comm=", "--pid",
str(self.process.pid)
]).split()
Yea makes sense.
Rebased in my favor: https://travis-ci.org/github/g1itch/PyBitmessage/builds/738705081
Almost clear: https://travis-ci.org/github/g1itch/PyBitmessage/builds/738955127
I added
os.path.exists
.I added this now.
TImeout expired every time on osx: https://travis-ci.org/github/g1itch/PyBitmessage/jobs/739252746
87 char line
if not
os.path.exists
it will be full wait untilpybitmessage -t
stops. See:https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/bitmessagemain.py#L180
https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/bitmessagemain.py#L371
Hmm https://travis-ci.org/github/g1itch/PyBitmessage/jobs/739258079
no fractional part in
st_mtime
: https://travis-ci.org/github/g1itch/PyBitmessage/jobs/739262652maybe
int(time.time())
?As I can see
OSError
raised whenos.path.exists(os.path.join(cls.home, 'singleton.lock')) is False
.@ -70,4 +122,3 @@
try:
if not cls._stop_process():
print(open(os.path.join(cls.home, 'debug.log'), 'rb').read())
cls.process.kill()
Why sleep 10 seconds if singleton.lock is already checked? What may happen?
No handlers could be found for logger "default": https://travis-ci.org/github/Bitmessage/PyBitmessage/builds/739215140#L1084
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
I don't understand the purpose, it's not used in code:
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
Why only on second pass?
@ -70,4 +122,3 @@
try:
if not cls._stop_process():
print(open(os.path.join(cls.home, 'debug.log'), 'rb').read())
cls.process.kill()
OK, I see. It is to start all threads and not fail test_threads and test_shutdown.
Ok I'll look throught this.
I see.
Ok makes sense.
Oh, now I get it.
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
I think it may be leftover from debugging, perhaps it isn't necessary anymore.
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
I don't understand the logic flow of the passes, this may be a leftover from debugging and perhaps isn't necesasry anymore.
I'll work on the requested changes.
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
This not fixes the test. I'll describe how it works, how it worked and how I wanted it to work a bit later.
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
I'll look at it.
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
A proper test should not rely on other tests side effects.
What I wanted to demonstrate in this particular test:
logger
fromdebug
it sets up the logging based onlogging.dat
configlogger = logging.getLogger('default')
set after the import will be the same as indebug
resetLogging()
the configuration will be reappliedAll that works only after the first import of
debug
because it callshelper_startup.loadConfig()
.How it worked before:
debug
or other module inducing config setup or appdata changedebug.log
in appdata remaining from core testsresetLogging()
You can reveal it by replacing all
tempfile.gettempdir()
bytempfile.mkdtemp()
as was suggested before.@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
I'm not sure that I can precisely reconstruct what's happening now. It places
logging.dat
which is used by subsequent runs of pybitmessage process and can be detected on second pass.@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
Maybe subclass this test case from
TestProcessProto
and check only the presence of pattern (severity and initial message)? Then we can replacelogging.getLogger('default')
by conventionallogging.getLogger(__name__)
, compose properlogging.dat
and check presence of all submodule names which write logs.@ -70,4 +122,3 @@
try:
if not cls._stop_process():
print(open(os.path.join(cls.home, 'debug.log'), 'rb').read())
cls.process.kill()
But I hope that 5 sec will be enough for any environment (on travis it works without delay). This delay is used before starting tests in any test case subclassed from
TestProcessProto
on each pass.I'm waiting to check the new approach: https://travis-ci.org/github/g1itch/PyBitmessage/builds/739605155
The cleanup of the core tests is here.
xenial, bionic and fedora31: OK, small hangup on focal, waiting for windows
https://travis-ci.org/github/g1itch/PyBitmessage/builds/739657803 - process based
TestLogger
and cleanup tweaks.@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
Only if it uses the same config directory. But the tests change the location of the config directory. I think this breaks the logic. You can see now that I reverted to your original logic intest_logger.py
, and it fails on travis-ci.org. I don't want to merge until this is resolved.Oh it worked. So maybe I don't understand it correctly.
I think all your feedback has been applied, and travis-ci passes. I think the rest of the issue can be resolved later, and this is ok to merge now. Let me know if you agree.
@ -35,11 +37,14 @@ level=DEBUG
handlers=default
'''
I wrote before that my original logic was wrong. Standalone tests should not import any module with side effects.
I debug my process-based variant, it succedes only on linux: https://travis-ci.org/github/g1itch/PyBitmessage/builds/740134631
Now I don't see any help from
get_active_config_folder()
and related code.It works on xenial on buildbot now.
So what now?
But it you remove initial
src/bitmessagemain.py -t
it may stop working.Well you can fix it later.
So apart from the logger do you have any other complaints?
While this version
TestLogger
is here any newly written test case may fail unexpectedly.get_active_config_folder()
code is doing nothing.Also I have one more assertion which should not fail. I'll prepare another draft PR so you can test it on your buildbot.
It fixes the
test_config.py
errors. The logger tests can be fixed in a separate PR.What fixes
test_config
is proper cleanup and guaranteed kill intearDownClass
- that's what I'm going to demonstrate in the new rebased branch.Ok then I close this and you can make a PR with your changes.