> On Mon, Mar 06, 2017 at 01:30:39PM +0200, Andrei Otcheretianski wrote: > > When saving a configuration, many fields are only saved only if they > > are set to a value different than the default value. > > So if the test sets a field to its default value and than saves the > > configuration, this value will not be saved to the config file and the > > test will fail. This requires this test to be updated if default > > values are changed. > > This is done on purpose. In most cases, there should be clear justification for > changing a default value and as such, it is convenient to have a test case clearly > highlight such changes so that no accidental changes get accepted. I agree that changing default values shouldn't be accidental, but this test doesn't really verify it. The test will fail only if the value used by the test is by chance equals to the default one. So maybe it's better to have a separate test that verifies the default values? We can prepare such test if you want. > > > Fix that by only verifying that fields that are set to a non-default > > value are written to the saved configuration. > > What is your use case for this? The current behavior seems more useful to me. In our internal tree we have different defaults and one of them is failing this test. So I wondered that it may be useful to have this specific test more robust to such changes. Andrei > > -- > Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
