QT for Python and TDD (Test Driven Development)
-
wrote on 10 Dec 2024, 19:27 last edited by
Pyside6 seems to use "lazy" creation.
For example, after creating a failing test for QMainWindow then I add it, and the test passes as it should.
Next, I wanted a menu bar. Since there was not one explicitly added by me I wrote a test for the menu bar expecting it to fail. The test passed.
Because PySide6 automatically creates a menuBar() lazily when creating a QMainWindow instance I need a different approach than testing for the existence of things I have not yet created.I need some insights on how to use TDD in the context of QT implemented via PySide6.
-
Pyside6 seems to use "lazy" creation.
For example, after creating a failing test for QMainWindow then I add it, and the test passes as it should.
Next, I wanted a menu bar. Since there was not one explicitly added by me I wrote a test for the menu bar expecting it to fail. The test passed.
Because PySide6 automatically creates a menuBar() lazily when creating a QMainWindow instance I need a different approach than testing for the existence of things I have not yet created.I need some insights on how to use TDD in the context of QT implemented via PySide6.
wrote on 10 Dec 2024, 19:34 last edited by JonB 12 Oct 2024, 19:35@Greg-Alvord
Just so you know, this has nothing to do with PySide (or Python). It is the behaviour of Qt'sQMainWindow. QMenuBar *QMainWindow::menuBar() constReturns the menu bar for the main window. This function creates and returns an empty menu bar if the menu bar does not exist.)
That's just how it is, and probably equivalents elsewhere.
-
wrote on 10 Dec 2024, 19:54 last edited by
OK. However, I still need to know how to apply TDD paradyme when building with a QT based package. If QT creates stuff in anticipation of it being used that is fine as long are there is a strategy for writing tests that fail when work has not yet been done.
-
OK. However, I still need to know how to apply TDD paradyme when building with a QT based package. If QT creates stuff in anticipation of it being used that is fine as long are there is a strategy for writing tests that fail when work has not yet been done.
@Greg-Alvord hi,
Are you creating a subclass of QToolBar ? Then check the type of what is returned.
Are you just creating a QToolBar and populate it before setting it ? Check that it should be not empty.
-
wrote on 10 Dec 2024, 20:50 last edited by
Thank you @SGaist.
I conclude that I am going to need a boat load of interium tests to discovery what was auto created after each TDD interantion to prepare for the next one. Not what I was expecting, but also not unreasonable. -
G Greg Alvord has marked this topic as solved on 10 Dec 2024, 20:51
-
No, you need to read the documentation of the classes you are going to use before writing your tests.
There's not that many cases like QMainWindow's tool bar.
Also, you should take the time to ponder about the test you are writing: do you really need a test to validate the presence of a QToolBar or do you rather need to test that when some action from that toolbar is triggered, some reaction happens ?
-
No, you need to read the documentation of the classes you are going to use before writing your tests.
There's not that many cases like QMainWindow's tool bar.
Also, you should take the time to ponder about the test you are writing: do you really need a test to validate the presence of a QToolBar or do you rather need to test that when some action from that toolbar is triggered, some reaction happens ?
wrote on 11 Dec 2024, 08:35 last edited by@SGaist said in QT for Python and TDD (Test Driven Development):
No, you need to read the documentation of the classes you are going to use before writing your tests.
This I agree with 100%.
There's not that many cases like QMainWindow's tool bar.
Ummm. That depends on what the OP regards as such a "case". I don't know. Libraries often create objects for you, which seems to be what they are not happy with. A
QTableWidgetrepresents a table view UI plus a data model. It creates it for you, though you can replace it. Some overloads ofQImage()allocate their own data area to copy the data passed in, some do not and use the data passed in as-is which must persist through its lifetime. And so on. I do not see which cases the OP will regard as problematic and which not. -
@SGaist said in QT for Python and TDD (Test Driven Development):
No, you need to read the documentation of the classes you are going to use before writing your tests.
This I agree with 100%.
There's not that many cases like QMainWindow's tool bar.
Ummm. That depends on what the OP regards as such a "case". I don't know. Libraries often create objects for you, which seems to be what they are not happy with. A
QTableWidgetrepresents a table view UI plus a data model. It creates it for you, though you can replace it. Some overloads ofQImage()allocate their own data area to copy the data passed in, some do not and use the data passed in as-is which must persist through its lifetime. And so on. I do not see which cases the OP will regard as problematic and which not.@JonB in that case the OP would be testing Qt rather than his own code.
Nothing wrong with writing tests that allows to understand and confirm how a given framework works as advertised but it should not be the base for the tests of your actual code as it is a different goal.
1/8