The last daily execution pointed out the following failure:
============================= test session starts ==============================
platform linux -- Python 3.9.13, pytest-7.0.0, pluggy-0.13.1
cachedir: .tox/py39/.pytest_cache
rootdir: /builds/kytos/of_core/of_core, configfile: pytest.ini
plugins: cov-3.0.0, asyncio-0.18.3
asyncio: mode=auto
collected 99 items
tests/unit/test_action.py ...... [ 6%]
tests/unit/test_flow.py ........... [ 17%]
tests/unit/test_main.py .......................F..... [ 46%]
tests/unit/test_match.py .... [ 50%]
tests/unit/test_msg_prios.py ......................... [ 75%]
tests/unit/test_utils.py .......... [ 85%]
tests/unit/v0x01/test_utils.py ....... [ 92%]
tests/unit/v0x04/test_utils.py ....... [100%]
=================================== FAILURES ===================================
_______________________ TestMain.test_request_flow_list ________________________
self = <of_core.tests.unit.test_main.TestMain testMethod=test_request_flow_list>
args = (<MagicMock name='update_flow_list' id='140403813278480'>, <MagicMock name='update_flow_list' id='140403813147168'>, <...cMock name='_check_overlapping_multipart_request' id='140403813201328'>, <MagicMock name='sleep' id='140403813316352'>)
mock_update_flow_list_v0x01 = <MagicMock name='update_flow_list' id='140403813278480'>
mock_update_flow_list_v0x04 = <MagicMock name='update_flow_list' id='140403813147168'>
mock_check_overlapping_multipart_request = <MagicMock name='_check_overlapping_multipart_request' id='140403813201328'>
@patch('time.sleep', return_value=None)
@patch('napps.kytos.of_core.main.Main.'
'_check_overlapping_multipart_request')
@patch('napps.kytos.of_core.v0x04.utils.update_flow_list')
@patch('napps.kytos.of_core.v0x01.utils.update_flow_list')
def test_request_flow_list(self, *args):
"""Test request flow list."""
(mock_update_flow_list_v0x01, mock_update_flow_list_v0x04,
mock_check_overlapping_multipart_request, _) = args
mock_update_flow_list_v0x04.return_value = 0xABC
mock_check_overlapping_multipart_request.return_value = False
self.napp._request_flow_list(self.switch_v0x01)
mock_update_flow_list_v0x01.assert_called_with(self.napp.controller,
self.switch_v0x01)
self.napp._request_flow_list(self.switch_v0x04)
> mock_update_flow_list_v0x04.assert_called_with(self.napp.controller,
self.switch_v0x04)
tests/unit/test_main.py:432:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <MagicMock name='update_flow_list' id='140403813147168'>
args = (<kytos.core.controller.Controller object at 0x7fb254068c70>, <MagicMock name='mock.switch' spec='Switch' id='140403811019792'>)
kwargs = {}
expected = "update_flow_list(<kytos.core.controller.Controller object at 0x7fb254068c70>, <MagicMock name='mock.switch' spec='Switch' id='140403811019792'>)"
actual = 'not called.'
error_message = "expected call not found.\nExpected: update_flow_list(<kytos.core.controller.Controller object at 0x7fb254068c70>, <MagicMock name='mock.switch' spec='Switch' id='140403811019792'>)\nActual: not called."
def assert_called_with(self, /, *args, **kwargs):
"""assert that the last call was made with the specified arguments.
Raises an AssertionError if the args and keyword args passed in are
different to the last call to the mock."""
if self.call_args is None:
expected = self._format_mock_call_signature(args, kwargs)
actual = 'not called.'
error_message = ('expected call not found.\nExpected: %s\nActual: %s'
% (expected, actual))
> raise AssertionError(error_message)
E AssertionError: expected call not found.
E Expected: update_flow_list(<kytos.core.controller.Controller object at 0x7fb254068c70>, <MagicMock name='mock.switch' spec='Switch' id='140403811019792'>)
E Actual: not called.
Running the same pipeline again returns success; if we keep repeating the tests, we eventually get the same error again.
I've already noticed that the test method that runs in a thread (i.e., using the run_on_thread or listen_to decorators) actually gives certain uncertainty. So maybe that is the cause.
Hi,
The last daily execution pointed out the following failure:
Running the same pipeline again returns success; if we keep repeating the tests, we eventually get the same error again.
I've already noticed that the test method that runs in a thread (i.e., using the
run_on_thread
orlisten_to
decorators) actually gives certain uncertainty. So maybe that is the cause.