Graphical QT Testing

[lakshyacis]

Graphical Qt Testing

Initial commit for the graphical Qt tests.
Build an automated script for Qt Interface-
-Generate address with a random label
-Generate addresses with passphrases
-Send a message and checks whether the message received or not
-Add the address in the subscription list
-Add the address in the blacklist and whitelist
-Tests for setting window.
-Tests for Inbox tab QTreeWidget PopMenu
Work is in progress. Kindly give me some feedbacks

[g1itch]

This is some bikeshead. Why don't you just write a unittest.TestCase class in the tests module and attach to test-mode? See an example: b75d9ec

[lakshyacis]

This is some bikeshead. Why don't you just write a unittest.TestCase class in the tests module and attach to test-mode? See an example: b75d9ec

Hello @g1itch . I tried this way, but GUI is not opening. The test result just displayed on the terminal.

[g1itch]

That is the nature of automated tests, they should not open any GUI or require X, because Travis CI has no X.

[lakshyacis]

That is the nature of automated tests, they should not open any GUI or require X, because Travis CI has no X.

Actually @g1itch . This is the automation graphical Qt test cases. Where the script automatically opens up the Qt interface and automatically fills the inputs of the different windows and waits for the response. So, that's why I didn't use the unit tests. The main purpose of these tests is to automate the Qt interface. These tests are just like the same we use Selenium automation for the web . Thanks

[g1itch]

OK, I don't want to automate the Qt interface. Unsubscribed.

The tests from tests package are used to check the new code from PR's to be sure that nothing is broken.

[PeterSurda]

@g1itch Similarly as the state.testmode tests the backend, this one tests the QT interface. It can run in xvfb just like I run the wine builds.

[g1itch]

@g1itch Similarly as the state.testmode tests the backend, this one tests the QT interface. It can run in xvfb just like I run the wine builds.

Anyway, I see no reason to introduce another argument and state variable, same for not using unittest. xvfb-run is what I searched for; need some time to find how to use it inside python.

[PeterSurda]

There are also other types of tests in addition to unit tests, so maybe it can be better with those instead.

Regarding xvfb, this is what I have in the buidlbot config:

wine32.addStep(steps.ShellCommand(
        command=["xvfb-run", "-a", "i386", "buildscripts/winbuild.sh"]
))

But I see you already have it in your ci branch so maybe that's enough too.

[PeterSurda]

Anyway, I see no reason to introduce another argument and state variable, same for not using unittest.

I'm ok with writing these tests as unit tests. I also would be ok with avoiding the state variable, the problem is that the initialisation of PyBitmessage is horrible. I'm sure you'll agree it needs to be refactored to do all these things cleanly. However, this requires someone with a lot of knowledge of PyBitmessage internals and a lot of time and testing. So I would find it acceptable to have another state variable now, with the refactoring being a longer term goal. Once we have a lot of automated tests available, the refactoring should be easier to do as well.

[PeterSurda]

So here is my current suggestion. Write a separate initialisation routine that will replace src/bitmessagemain.py, which will initiate the test environment for QT. It doesn't have to do everything that the current bitmessagemain.py does, because we can avoid API, curses, daemon, maybe multiprocessing, ... This way we should be able to avoid a new variable in state, and perhaps rewrite the tests as unit tests too. It does involve some code duplication but in the future once the initialisation is refactored it can be reintegrated.