Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize settings to use common code but separate prefixes #396

Merged
merged 10 commits into from Sep 14, 2019

Conversation

CharliePoole
Copy link
Contributor

@CharliePoole CharliePoole commented Sep 5, 2019

Fixes #315

  • Removes all Setting definitions from the experimental GUI
  • Both GUIs now use Settings in the model but with different prefixes: TestCentric vs Experimental.
  • It's up to each GUI, whether to use a particular property or not.
  • A few settings are changed and will need to be reset in normal use or deliberately by the user.

@CharliePoole CharliePoole changed the title Issue 315 Reorganize settings to use common code but separate prefixes Sep 5, 2019
@CharliePoole CharliePoole requested a review from a team September 5, 2019 01:58
Copy link
Contributor

@mikkelbu mikkelbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks god to me, and it is always great to remove code :)

@@ -66,7 +65,7 @@ public override void OnTestLoaded(TestNode testNode)

_view.Tree.Add(treeNode);

SetInitialExpansion(displayStyle, treeNode);
SetInitialExpansion((TreeDisplayStyle)displayStyle, treeNode);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a bit confusing that in testcentric.gui Gui.TestTree.InitialTreeDisplay contains a DisplayStyle and in the experimental gui is contains a TreeDisplayStyle, and these enums have the same values (with the same names).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I'll take another look.

Generally, I resisted making any changes that were "incidental" to the big change I was making, i.e. unifying the handling of settings. In this case, I kept the different definitions because I thought the experimental value might have more things added in the future and because the knowledge of the different ways of expanding the tree don't belong in the model. However, the name is rather bad, since it doesn't contain the word "expansion," which is what this setting is all about.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed both to InitialTreeExpansion

src/TestModel/model/Settings/MiniFormSettings.cs Outdated Show resolved Hide resolved
src/TestModel/tests/SettingsTests.cs Show resolved Hide resolved
public void GetSettingWithDefault_WhenPresent_ReturnsValue(string name, object expected)
{
_settings.SaveSetting(name, expected);
object actual = _settings.GetSetting(name);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are not "getting" the setting with default, so the name of the test is a bit misleading.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! The test is not testing what it's supposed to test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK! So reviewing this led me to reconsider the entire structure of SettingsGroupTests. It relied on Fakes.SettingsService duplicating the semantics of the engine's SettingsService. That doesn't really make sense to me now that I look at it. It's too much effort to keep the fake up to date. I'm converting to use of a mock instead. Once I push the commit, I'd appreciate your taking another look at these tests.

src/TestModel/tests/SettingsGroupTests.cs Outdated Show resolved Hide resolved
public void WhenSettingIsNotValid_DefaultSettingIsReturned()
{
_settings.SaveSetting( "X", "1y25" );
Assert.That(_settings.GetSetting( "X", 42 ), Is.EqualTo(42));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some spaces before/after the parenthesis in this method. Also I had to think about why 1y25 was invalid. It was only when I looked at the code in VS I noticed that 42 forces the returned value to be an integer. I'm not sure if we could make this more clear by changing GetSetting( to GetSetting<int>( even though the type parameter is redundant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than the redundant Type parameter, I changed the name of the test and added a comment.

@CharliePoole CharliePoole merged commit 9339e13 into master Sep 14, 2019
@CharliePoole CharliePoole deleted the issue-315 branch September 14, 2019 15:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reorganize Settings
2 participants