TestProjectNaming in options window does not match settings about unitverse HOT 12 CLOSED

It's beautiful ❤️ Thanks for taking the time to make it!

My only feedback is the description text is quite small and hard to read. Making it larger and on same line as checkbox would be more readable I think.

from unitverse.

Full file:

[GenerationOptions]
AutoDetectFrameworkTypes=True
FrameworkType=NUnit3
MockingFrameworkType=Moq
AllowGenerationWithoutTargetProject=True
TestProjectNaming={0}.Test
TestFileNaming={0}Test
TestTypeNaming={0}Test
UseFluentAssertions=False
EmitUsingsOutsideNamespace=True
PartialGenerationAllowed=True
EmitTestsForInternals=True
AutomaticallyConfigureMocks=True
EmitSubclassForProtectedMethods=True
ArrangeComment=Arrange
ActComment=Act
AssertComment=Assert

[NamingOptions]
CanConstructNamingPattern=CanConstruct
CannotConstructWithNullNamingPattern=CannotConstructWithNull{parameterName}
CannotConstructWithInvalidNamingPattern=CannotConstructWithInvalid{parameterName}
CanInitializeNamingPattern=CanInitialize
CannotInitializeWithNullNamingPattern=CannotInitializeWithNull{memberName}
CannotInitializeWithInvalidNamingPattern=CannotInitializeWithInvalid{memberName}
CanGetNamingPattern=CanGet{memberName}
CanSetAndGetNamingPattern=CanSetAndGet{memberName}
CanSetNamingPattern=CanSet{memberName}
IsInitializedCorrectlyNamingPattern={memberName}IsInitializedCorrectly
ImplementsIEnumerableNamingPattern=ImplementsIEnumerable{typeParameters}
ImplementsIComparableNamingPattern=ImplementsIComparable{typeParameters}
ImplementsIEquatableNamingPattern=ImplementsIEquatable{typeParameters}
CanCallNamingPattern=CanCall{memberName}
PerformsMappingNamingPattern={memberName}PerformsMapping
CannotCallWithNullNamingPattern=CannotCall{memberName}WithNull{parameterName}
CannotCallWithInvalidNamingPattern=CannotCall{memberName}WithInvalid{parameterName}
CanCallOperatorNamingPattern=CanCall{memberName}Operator
CannotCallOperatorWithNullNamingPattern=CannotCall{memberName}OperatorWithNull{parameterName}
TargetFieldName=sut
DependencyFieldName={parameterName:camel}Mock

[StrategyOptions]
ConstructorChecksAreEnabled=False
ConstructorParameterChecksAreEnabled=False
InitializerChecksAreEnabled=True
InitializerPropertyChecksAreEnabled=False
MethodCallChecksAreEnabled=True
MappingMethodChecksAreEnabled=True
MethodParameterChecksAreEnabled=False
IndexerChecksAreEnabled=True
PropertyChecksAreEnabled=True
InitializedPropertyChecksAreEnabled=True
OperatorChecksAreEnabled=True
OperatorParameterChecksAreEnabled=False
InterfaceImplementationChecksAreEnabled=True

from unitverse.

I'm not sure I understand? If you mean that the settings shown in Tools -> Options -> Unitverse don't reflect what you have set in a .unitTestGeneratorConfig file - then that's expected behavior. The options in Tools -> Options -> Unitverse are stored by Visual Studio itself, and are instance-specific - so they apply to all solutions. Then, those options can be overridden by a .unitTestGeneratorConfig file when you generate tests - but only for the purposes of generating tests. The overrides don't persist back to the Visual Studio config set...

from unitverse.

from unitverse.

Ok. I'm unlikely to be able to do that any time soon - it's actually a reasonably big job and you have to register an editor for the file type and have it show up as a GUI where you would have a document open. Given it's fairly easy to edit the text file and it's a lot of work I don't think it adds enough value right now.

from unitverse.

@CoenraadS - some of the UI work for 0.106 actually lays the groundwork for this (although surfacing that as an editor in VS can still be a pain).

I do have one question - if you are editing a .unitTestGeneratorConfig with the UI - would you expect it to be able to edit only the fields that are present in the file? It's perfectly possible to just have a config file with one setting in it, leaving the others to defaults (or perhaps another config file higher up in the folder structure). I am wondering if it would be required to support something where each setting had a checkbox next to it, which you could untick if you didn't want that setting to be a part of the saved file.

Interested to know your thoughts. 👍

from unitverse.

I would expect every setting to be there, even if its not in the file.

I don't think having an option to include it in the file or not is needed, the editorconfig UI doesn't do that, I use it as reference behaviour.

from unitverse.

Yeah, I know the editorconfig UI doesn't do that - I'm just not sure I think that's necessarily 'correct'. At least it's 'expected' though.

I might make a first pass that just saves everything, and then see if selectivity needs to be added later on.

from unitverse.

@CoenraadS Ok, after much late night swearing, this is available in 0.109. I have also added a section to the configuration docs at the top to explain the hierarchy of options more clearly. Please can you let me know if that works for you? 👍

from unitverse.

The same templates are used for the generation UI and the config editor UI - so I might just bump the font size a little. Ideally you would be able to zoom it with Ctrl+Mouse Wheel like you can for the code editor... Leave it with me. 👍

from unitverse.

Ok - addressed 0.110 - the description text is a little bigger and to the right of the checkboxes for boolean options. Also, on both the config editor UI and the generation UI you can zoom in with Ctrl+MouseWheel and the level of zoom will be remembered when the dialog opens again.

Think that should sort it out a bit 👍

from unitverse.

Closing for now - thanks for the issue ❤

from unitverse.