search

andreikop / enki

A text editor for programmers
http://enki-editor.org
GNU General Public License v2.0
161 stars 39 forks source link

Migrate to py.test #359

Open bjones1 opened 8 years ago

bjones1 commented 8 years ago

I think we should migrate Enki to using py.test. It's really an amazing framework; fixtures, in particular, are very helpful. Also, it has a pytest-qt plugin to make testing pyqt apps much easier. py.test supports unittest-style tests (https://pytest.org/latest/unittest.html), so the transition should be fairly smooth.

Your thoughts?

andreikop commented 8 years ago

I haven't used py.test. But I think it will be difficult to persuade me to migrate to it. unittest is a standard libraryr and it known by the majority of Python programmers. With py.test we will have one more dependency and will have to learn one more library.

bjones1 commented 8 years ago

It's worth a try! It's made me much more productive. One quick example: to run an individual test, I usually use python -m unittest test_plugins.test_preview.PreviewTest.test_sync13, while I can easily select a test using py.test -k sync13. And lots of more good things...

andreikop commented 8 years ago

@bjones1, I'm trying to fix test freezes on py3 but don't know how. Probably something is wrong with QApplication main loop usage. i.e. while ./test_preview_sync.py Test.test_sync7; do :; done freezes after 10-20 iterations. It seems like your are already familiar with py.test. Maybe you could try to port the test to pytest-qt and check if it still fails?

andreikop commented 8 years ago

It seems like all Qt code must be running in the main loop, and the loop must be executed only once.

andreikop commented 8 years ago

The crashes have gone after update to latest Qt. @bjones1, what are other advantages of py.test except shorter command line?

bjones1 commented 8 years ago

I'm very excited to hear that Qt updates have fixed stability problems. Should we add a list of "do not use" Qt versions in the readme, to prevent users from seeing this? Or perhaps put in code that checks the Qt version and exits if it's bad?

There are a lot of great py.test features. The best is fixtures -- all the setup/teardown code becomes much more modular and simpler. Built-in qt support is also very nice. Finally, we can use our existing tests (py.test will run Python unittest code) and slowly migrate to nice py.test features.