Graphical QT Testing #1603

2020-02-14T08:38:55+01:00

lakshyacis commented

2020-02-14 08:38:55 +01:00

(Migrated from github.com)

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

**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 commented

2020-02-14 09:05:32 +01:00

(Migrated from github.com)

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

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 commented

2020-02-14 14:33:30 +01:00

(Migrated from github.com)

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.

> 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](https://github.com/Bitmessage/PyBitmessage/commit/b75d9ecf01d85aa9fd1051a7298195b46534c0b1) Hello @g1itch . I tried this way, but GUI is not opening. The test result just displayed on the terminal.

g1itch commented

2020-02-14 15:09:41 +01:00

(Migrated from github.com)

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

lakshyacis commented

2020-02-14 15:29:53 +01:00

(Migrated from github.com)

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

> 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 commented

2020-02-14 15:38:57 +01:00

(Migrated from github.com)

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.

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 commented

2020-02-15 02:25:02 +01:00

(Migrated from github.com)

@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 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 commented

2020-02-19 17:52:42 +01:00

(Migrated from github.com)

@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.

> @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 commented

2020-02-19 18:13:12 +01:00

(Migrated from github.com)

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.

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 commented

2020-02-20 08:46:14 +01:00

(Migrated from github.com)

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.

> 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 commented

2020-12-25 13:29:09 +01:00

(Migrated from github.com)

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.

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.

This repo is archived. You cannot comment on pull requests.

No reviewers