lholman
commented
9 years ago @AwaNoodle I understand the logic behind your question, from a OneBuild consumer perspective, however let me try and explain my thoughts on why I don't think this is the best approach for OneBuild.
As you know, OneBuild is designed to be very convention based, that means, for it to work as elegantly as it does and with zero configuration (for the vast majority of cases) it is necessary to set these conventions, that means the consumer will have to abide by those conventions for OneBuild to work for them, in certain situations that will definitely require minor changes to the Visual Studio solution/project(s) to accommodate those well defined conventions, in this case, that is changing the names of existing projects.
More specifically, if OneBuild was to support the more common .unittest.dll or .tests.dll patterns in DLL's, and pass any DLL that match those patterns through the NUNit runner, as you suggest, then we will also need to do the same if and when we support additional test frameworks, which is likely. The Invoke-UnitTests module will also have to pass all DLL's through all test frameworks, which I believe will become time consuming, cumbersome and ultimately require us to do flow control by exception, i.e. catching the exceptions from the unit test framework runners.
For now I would rather stick with the defined convention (below) and here, that will scale out for additional unit test frameworks, does that seem fair?
Invoke-UnitTests
- To be executed with NUnit, NUnit test assemblies must
- Contain "nunit" (case-insensitive) in their assembly and directory names.
- Be output into a common output folder named \bin, regardless of Visual Studio build configuration.
Could Onebuild support the more common .unittest.dll or .tests.dll as a pattern for picking up unit tests? If a test dll with another framework is passed into the nunit runner it won't find anything so there won't be an issue with matching them.