I am trying to run a GUI test using pytest and pywinauto. When I run the code normally, it does not complain.
However, when I am doing it via pytest, it throws a bunch of errors:
Windows fatal exception: code 0x8001010d
Note that the code still executes without problems and the cases are marked as passed. It is just that the output is polluted with these weird Windows exceptions.
What is the reason for this. Should I be concerned?
def test_01():
app = Application(backend='uia')
app.start(PATH_TO_MY_APP)
main = app.window(title_re="MY_APP")
main.wait('visible', timeout=8) # error occurs here
time.sleep(0.5)
win_title = f"MY_APP - New Project"
assert win_title.upper() == main.texts()[0].upper() # error occurs here
This is an effect of a change introduced with pytest 5.0.0. From the release notes:
#5440: The faulthandler standard library module is now enabled by default to help users diagnose crashes in C modules.
This functionality was provided by integrating the external pytest-faulthandler plugin into the core, so users should remove that plugin from their requirements if used.
For more information see the docs: https://docs.pytest.org/en/stable/usage.html#fault-handler
You can mute these errors as follows:
pytest -p no:faulthandler
I had the same problem with Python 3.7.7 32-bit and pytest 5.x.x. It was solved by downgrading pytest to v.4.0.0:
python -m pip install pytest==4.0
Perhaps all Python versions are not compatible with the newest pytest version(s).
My workaround for now is to install pytest==4.6.11
With 5.0.0 the problem occurs the first time.
W10 box.
Have this problem using pytest 6.2.5 and pytest-qt 4.0.2.
I tried np8's idea: still got a horrible crash (without message).
I tried Felix Zumstein's idea: still got a horrible crash (without message).
Per this thread it appears the issue (in 'Doze) is a crap DLL.
What's strange is that pytest-qt and the qtbot fixture seem to work very well... until I get to this one test. So I have concluded that I have done something too complicated in terms of mocking and patching for this crap 'Doze DLL to cope with.
For example, I mocked out two methods on a QMainWindow subclass which is created at the start of the test. But removing these mocks did not solve the problem.
I have so far spent about 2 hours trying to understand what specific feature of this test is so problematic. I am in fact trying to verify the functioning of a method on my main window class which "manufactures" menu items (QWidgets.QAction) based on about 4 parameters.
At this stage I basically have no idea what this "problem feature" is, but it might be the business of inspecting and examining the returned QAction object.
Related
I want to run JdeRobot drone_cat_mouse on my Ubuntu 20.04. I'm using ROS Noetic and has faithfully followed these installation instructions. Everything it told me to test was working properly.
When I first ran roslaunch drone_cat_mouse.launch, there was an import error for teleopWidget and sensorsWidget which I fixed by using relative imports. Then I had an error No module named qfi.
Unlike teleopWidget and sensorsWidget, I couldn't find the qfi module in the JdeRobot/drones source code. So I googled it, and the only relevant result that popped up was this, which led to this link. They said to:
sudo touch /usr/lib/python2.7/dist-packages/qfi/__init__.py
But I ran that command and this happened!
Not even pip has a "qfi" module!
So I thought to check JdeRobot's entire repository. Turns out it was in JdeRobot/base, and that repo is not maintained anymore!
After further digging, there was this issue which basically tells us forget about it and move to the web release! But I can't, circumstances forced me to use the source code option (deliverables are drone_cat_mouse.world and my_solution.py, it's impossible for me to get the former in the docker web version and the latter's format is different between the source code version and the web version).
In a nutshell, how do I fix this qfi module problem so that I can run the exercises from source like these people?
I'm just stupid, as usual. all I need to do was clone https://github.com/JdeRobot/ThirdParty, get the qfi module, copy it to
~/catkin_ws/src/drones/rqt_drone_teleop/src/rqt_vel_teleop/ and replace all qfi imports with its relative import version. All common sense
No errors in terminal, gazebo runs, but somehow the rqt widget for drone vision never appears.
Forget it, I'm giving up on this dumpster fire of a program.
Edit: I did another fresh install, followed the steps, noticed troubleshooting for qfi which required qmake, but same end result
If you're trying to launch drone_cat_mouse there is an issue with the namespace of the RQT widget that occurs when you try to launch it.
Namely, the topics that exist for drone_cat_mouse are prefixed by cat/ or mouse/. But RQT will try to access these topics without the prefix and run into an error. Alternatively, since you have a local install, you can try to run the code manually by running
python my_solution.py
Just make sure the change the area where the DroneWrapper class was called in the following manner:
HAL = DroneWrapper('drone', 'cat/')
Here 'drone' is the name of the node you are creating and 'cat/' is the namespace given to the DroneWrapper Class.
I unit testing python code and running command pytest --cov, test is running fine but coverage is not getting displayed and error is
INTERNALERROR>raise CoverageException("Couldn't use data file {!r}:{}".format(self.filename, msg))
INTERNALERROR> coverage.misc.CoverageException: Couldn't use data file'C:\\Users\\Desktop\\Pytest\\.coverage': Safety level may not be changed inside a transaction
Need help with this problem?
This has been mentioned a few times in the coverage.py issues, and the eventual discovery was that it's a bug in Python 3.6.0, but if you use 3.6.1 or later, you will be fine.
If that doesn't cover your case, feel free to open an issue with details of how to reproduce.
Could be related to https://github.com/nedbat/coveragepy/issues/883#issuecomment-650562896 if you're using multiple pytests in parallel, in which case specifying a distinct coverage file for each run fixes it, like:
export COVERAGE_FILE=.coverage.SOMETHING_SPECIFIC_FOR_EACH_RUN
Use coverage==6.3.1
This works for me
Link to certain version https://pypi.org/project/coverage/6.3.1/
I am trying to make a standalone application using py2app with python3:
python3 setup.py py2app --packages=PyQt5
Everything seems to work just fine. But when one launches the application, the following errors are caught in Mac console:
14/04/16 13:27:27,688 app[98583]: objc[98583]: Class RunLoopModeTracker
is implemented in both
/Users/muammar/github/app/dist/app.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
and /usr/local/Cellar/qt5/5.6.0/lib/QtCore.framework/Versions/5/QtCore.
One of the two will be used. Which one is undefined.
That is also reported for the classes: NotificationReceiver, QCocoaPageLayoutDelegate and others.
I read elsewhere, that placing a qt.conf file next to the application as suggested here should solve the problem. But actually it does not work in my case. Does anybody know how to avoid this problem?.
For those having this problem, I fix it by doing the following:
python3 setup.py py2app --packages=PyQt5
cp -R /usr/local/Cellar/qt5/5.6.0/plugins dist/mya.app/Contents/PlugIns
macdeployqt dist/my.app
The problem is gone, and it works everything OK.
I'm a complete new starter when it comes to writing python unittests and I know it's far far better and easier to write the tests before the code but I thought I'd start by contributing to a github project and fixing a few small issues and giving it a go.
One issue I was fixing was that if a argument wasn't given to an method, it would actually remove the argument on the server. I should mention that this project is a client for a REST API. This was easy enough to fix but I thought it would be good to write a test for it.
The code of the broken method is included within a class:
def edit_device(self, device, nickname=None, model=None, manufacturer=None):
data = {"nickname": nickname}
iden = device.device_iden
r = self._session.post("{}/{}".format(self.DEVICES_URL, iden), data=json.dumps(data))
I then was going to use Mock to mock the responses of the REST API using their documentation as the guide (it includes example responses).
The issue I am having is I have written my test as:
#mock.patch('pushbullet.pushbullet.requests.Session.get', side_effect=mocked_requests_get)
#mock.patch('pushbullet.pushbullet.requests.Session.post', side_effect=mocked_requests_post)
class TestPushbullet(object):
def test_edit_device_without_nickname(self, mock_get, mock_post):
pb = pushbullet.Pushbullet("API_KEY")
device = pb.devices[0]
new_device = pb.edit_device(device)
assert new_device.nickname == device.nickname
This seems to work correctly, the methods mocked_requests_get and mocked_requests_post get called. If I run this test within eclipse PyDev using pyUnit to run the pytest - it fails, as I expect. If I run the tests using nose it also fails, again perfect. If I run the test using py.test on the command line, it passes.
If I use the pytest.set_trace() as the first line in mocked_requests_post I can print args and it shows that the nickname is in fact not None and still set to what it is on the server (i.e. device.nickname so the assertion passes)
I can't for the life of me work out why py.test is not picking up the change in json from the self._session.post. If I change the iden in the URL format, it does indeed pick up that change, however changing the data body it does not.
Am I doing something intrinsically wrong? I can't see why py.test would pass and nose would fail on the same code.
EDIT: on the command line I'm running py.test path/to/single_test_file.py and the test file has only the single test method I've pasted above.
Finally worked it out, I must have installed the client package into python previous to deciding to write the tests. It looks like the command line py.test was therefore reading the client package from the true source (via pip install) whereas the IDE was reading it from the development package I had in eclipse.
Solution is to remove the package: pip uninstall <package>
Reinstall the development package: pip install -e . (when in the root development directory)
I am running a basic script that sets up the django environment by itself, to enable me to test the ORM features of django without having to implement web pages. The script then imports one of the types defined in my models. This error doesn't happen when I run this script from iPython, only from eclipse. Simply doing this import causes a weird exception like the following:
Exception AttributeError: "'NoneType' object has no attribute 'print_exc'" in <bound method Signal._remove_receiver of <django.dispatch.dispatcher.Signal object at 0x026802B0>> ignored
My script is as follows:
from django.core.management import setup_environ
import settings
setup_environ(settings)
from stats.models import Person
for p in Person.objects.all():
print p.Name
After importing an existing Django project in Eclipse I had the same AttributeError
I just removed the *.pyc files... and it works... !?
right click on project ->pyDev -> remove *.pyc, *.pyo, ...
After some judicious googling, I'd say that Eclipse is causing the problem and that it may be hard to trace. print_exc is a function in Python's traceback module. Eclipse may be trying to show you a traceback, failing, and eating the result in the process.
I think a reasonable workaround would be to continue work on this script in a tool that doesn't present you with inscrutable errors. You may find an actual (fixable) error in your code, or you may find that Eclipse was raising a false alarm due to a bug in its Python integration.
If at that point you're unsure whether there is a problem with your code, adding some tests might be helpful.
Its possible that eclipse is using a different version of the python interpreter?
Could you give more details, such as the Person model.
Without seeing that I would guess the model attribute is meant to be in lowercase (ie p.name)
As far as i see, you do not havbe any problem with importing your modules. Try this to check if everything you need is ready for you. Probably that would not be the reason of your problem but better you check it too
iPuthon imports django system path automatically, so what you need is alresdy ready under your hands.
import sys
sys.path
check this out to see if all you need is there when you run it from eclipse, fiff with ipython result...