Exploring the Unit Test Generator VS Extension v1.RC Feedback and Bug Resolutions
We are busy with the final bug bash for Unit Test Generator and in this post we will look at some of the feedback and bug resolutions.
Why do we not have 1:1 feature parity with the previous in-the-box feature?
The Unit Test Generator is not about pure feature re-enablement, but instead embraces the new test architecture, provides additional functionality and support for other frameworks. We discussed the feature of the extension with the community and feature team extensively, realising that there is no silver bullet.
We agreed not re-introduce all the previous functionality, but instead focus on extensibility and new features. We will soon have the version 1 wrapped up, but before we consider a v2 we will take a tiny bit of breathing room and listen to the community before raising a v2 idea on Visual Studio UserVoice.
In essence we will view the testing world from a different perspective, listen and analyse feedback …
Which v1.RC bugs have we addressed so far?
Resolved
- 8466 Bug: Annoying bug which creates one new test project per method
- 8547 Bug: Use a resource string for static strings
- 8373 Bug: When generating tests for class to new framework a test is misplaced
- 8393 Bug: Use a resource string for the error message
- 8372 Bug: Project not selected if changed Target Framework
- 8375 Bug: Separate test projects and classes are created, when one test project is expected.
- 8377 Bug: VB.NET Test Class has incorrect Namespace with duplicated string within the Namespace like A.A.ClassName
- 8696 Bug: Format Text not disabled when project/class is selected
New feature implemented
- 8478 Bug: Configurable namespace needed
Scratching under the bug covers
8478 - Bug: Configurable namespace needed
The latest build has added a new setting on the configuration dialog, which will allow you to tweak the default behaviour:
Vinicius Hana Talks about 8377 - Bug: VB.NET Test Class has incorrect Namespace with duplicated string within the Namespace like A.A.ClassName
Bug 8377 reports that the generated test class has a duplicated namespace. The namespace for test classes was configured to be the same as the source class, plus ".Tests". Thus, our code queries EnvDTE for the source class's namespace at some point. However, EnvDTE was already giving us a duplicate namespace for the source class, which made me believe that there was a bug in EnvDTE itself.
Dustin from the product team then explained to us a possible reason for this: Visual Basic explicitly declared namespaces are concatenated with the project's namespace. This happens to be exactly the case we're dealing with, since the Code Quality class sample that triggers this behavior has both an explicit namespace declaration (namescls.png) and a root namespace definition for the project (rootnames.png).
What I've done, in order to confirm this, is to remove the namespace explicit declaration inside the class definition (nonames.png) of our quality test project. After that, the generated test class stops having its namespace duplicated (fixednames.png). The source class that triggered everything is located in $/VisualStudio.ALM/vsarUnitTestFx/main/code quality/VBTestProject/BasicPublicClass.vb, notice the explicit namespace declaration at line 18.
Hope it helps clarifying the situation, but please let me know if it doesn't.
Related posts