Add GCU empty input test to verify functional usage and valid configDB

[wen587]

Description of PR

Summary: Add empty input test before GCU tests to check GCU feature and if current configDB is valid
Fixes # (issue)

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• Test case(new/improvement)

Back port request

• 201911
• 202012

Approach

What is the motivation for this PR?

During PR test, there will have some changes on config DB. If the configDB does not pass yang validation, it will fail on the first GCU test: generic_config_updater/test_aaa.py. This empty input test is to verify if it is an invalid config DB causes the failure.

How did you do it?

Add empty input test case.

How did you verify/test it?

Run test of sonic-mgmt/tests/generic_config_updater/test_empty_input.py on KVM

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[qiluo-msft]

If your intention is to test "there will have change on config DB. It will fail on generic_config_updater/test_aaa.py". Then you need to add a new test case into test_aaa.py. The testcase has a pre-condition of configDB changing in some specific way.

If your intention is to test "invalid config DB cause the failure". I think it has nothing to do with test_aaa.py. Then you can use a test case like in your PR, and the test case has a pre-condition of invalid configDB.

[wen587]

If your intention is to test "there will have change on config DB. It will fail on generic_config_updater/test_aaa.py". Then you need to add a new test case into test_aaa.py. The testcase has a pre-condition of configDB changing in some specific way.

If your intention is to test "invalid config DB cause the failure". I think it has nothing to do with test_aaa.py. Then you can use a test case like in your PR, and the test case has a pre-condition of invalid configDB.

I mean the second intention. It fails at test_aaa.py just because it is the first GCU test. Also update in Description

[qiluo-msft]

setup_env

Seems that you are assume there is some pre-condition before you run this test case.

Suggest make the pre-condition of invalid configDB explicit. So it will always be tested in a reproducible fashion.