[chirp_devel] TOX testing - potential unexpected condition?
I've been working on the FT450d/450 changes, and was having issues getting through TOX. The problem was set and test special memories.
On the FT450/450D, you can use the CLAR button to 'clear" a memory (which really just makes it not visible for the PMS memories), and the PMS upper and lower memories all allow this.
In my test image, I have a couple of the PMS memories blanked out. In the FT450/D py get memory routines we set mem.empty = true to keep them from displaying on the gui.
When the test_edges.py test_get_set_specials routine tries to set the special memories, it does not clear the mem.empty to False after reading what's already there.
The FT450/D set special memory routines see an incoming request for an "empty" memory, and they make no changes and do not return a memory element. (as expected). The test_get_set_specials routine barfs on this, as the memory element returned is not what they expected.
I added the m1.empty = False statement to the routine test_edges.py and the test now passes properly for the cleared memory.
I ran a TOX with the full set of files in image and driver directories, and it screwed up 10 other radio models.
While I would love for Chirp to accurately reflect what is on the radio, I'm concerned about perturbing the other radio models. (Just the testing obviously)
Looking for comments/suggestions.
Regards,
Bill
Result Test Duration Links Failed tests/test_drivers.py::TestCaseEdges_Icom_IC-U82::test_get_set_specials 222 ms Failed tests/test_drivers.py::TestCaseEdges_Icom_IC-E90_Radio::test_get_set_specials 00:00:02 Failed tests/test_drivers.py::TestCaseEdges_Kenwood_TM-D710G_CloneMode::test_get_set_specials 842 ms Failed tests/test_drivers.py::TestCaseEdges_Kenwood_TM-D710_CloneMode::test_get_set_specials 296 ms Failed tests/test_drivers.py::TestCaseEdges_Kenwood_TH-D74_clone_mode::test_get_set_specials 00:00:03 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT-1D_R::test_get_set_specials 00:00:06 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT-817ND_US::test_get_set_specials 00:00:02 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT-857_897_US::test_get_set_specials 803 ms Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT3D_R::test_get_set_specials 00:00:07 Failed tests/test_drivers.py::TestCaseEdges_Yaesu_FT2D_R::test_get_set_specials
In my test image, I have a couple of the PMS memories blanked out. In the FT450/D py get memory routines we set mem.empty = true to keep them from displaying on the gui.
When the test_edges.py test_get_set_specials routine tries to set the special memories, it does not clear the mem.empty to False after reading what's already there.
The FT450/D set special memory routines see an incoming request for an "empty" memory, and they make no changes and do not return a memory element. (as expected). The test_get_set_specials routine barfs on this, as the memory element returned is not what they expected.
I added the m1.empty = False statement to the routine test_edges.py and the test now passes properly for the cleared memory.
Well, much of chirp expects those specials to not be empty or deletable. However, the new UI technically supports it. I'm guessing maybe some of those fails are because those radios have empty in the immutable set, but I'd have to take a look.
While I would love for Chirp to accurately reflect what is on the radio, I'm concerned about perturbing the other radio models. (Just the testing obviously)
The easy thing to do for the moment is just make all the specials never empty in your driver, which will make it like basically every other radio. I'll have a look at the failures when we set empty=False in the test.
--Dan
Well, much of chirp expects those specials to not be empty or deletable. However, the new UI technically supports it. I'm guessing maybe some of those fails are because those radios have empty in the immutable set, but I'd have to take a look.
This, but also some of the radios return freq=0 for empty ones, so a slight tweak was needed to pick something reasonable. Put this under your change and you should be good I think:
https://github.com/kk7ds/chirp/pull/801
--Dan
participants (2)
-
Dan Smith -
wcurlew＠juno.com