Less boilerplate code in the actual test data.
Depends on D20031
ngraham | |
astippich | |
apol |
Baloo | |
Frameworks |
Less boilerplate code in the actual test data.
Depends on D20031
LANG=C ctest
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
+1 to _data splitting, makes a lot of sense.
autotests/propertyinfotest.cpp | ||
---|---|---|
71–102 | Is the struct really necessary? |
autotests/propertyinfotest.cpp | ||
---|---|---|
71–102 | This saves adding the QVariant(...) around each value, and avoids the repeated formatting of the row name/data index. The property enum is used twice in each addRow. |
autotests/propertyinfotest.cpp | ||
---|---|---|
71–102 | And instead it makes you create a weird local struct and loop to feed to QTest. I don't find it very convincing. |
autotests/propertyinfotest.cpp | ||
---|---|---|
71–102 | First 2 rows expanded, just for you: QTest::addRow("%s", PropertyInfo(DiscNumber).displayName().toUtf8().constData()) << PropertyInfo(Property::DiscNumber) << true << QVariant(2018) << QStringLiteral("2018"); QTest::addRow("%s", PropertyInfo(Title).displayName().toUtf8().constData()) << PropertyInfo(Property::Title) << true << QVariant(QStringLiteral("Title")) << QStringLiteral("Title"); |
autotests/propertyinfotest.cpp | ||
---|---|---|
71–102 | Still not convinced? |
@apol - do you have a proposal how to avoid the "weird struct" and still keep it readable? Preferably, no repetition of the Property, and no extra explicit constructors.