Today we are releasing Gallio and MbUnit v3.0.6 Update 1. This release fixes a regression in the ReSharper support and adds a couple of new features.
- Added support for TestDriven.Net category filters.
- Added support for more powerful inclusion/exclusion test filter expressions.
- Fixed ReSharper v3.1, v4.0 and v4.1 hangs.
- Increased NCover v1.5.8 timeout.
- Adopted new assembly version numbering scheme.
Download here: http://www.gallio.org/Downloads.aspx
Documentation here: http://www.gallio.org/Docs.aspx
Inclusion / Exclusion Filters
Gallio provides a mechanism for filtering the set of tests to run. This is typically used to select some subset, for example to run all tests except for integration tests.
However, the filter grammar used in previous versions could not correctly express an exclusion constraint. Several people noted that filters like "not Category: Integration" did not in fact work due to a logical error introduced by a change in how Gallio applies filters. Oops.
In this update we have added a more concrete concept of inclusion and exclusion filters by extending the filter syntax with include and exclude clauses.
Here are a few examples using Gallio.Echo. The same filter syntax is used universally throughout Gallio so you can use them with NAnt, MSBuild, and PowerShell as well.
- Gallio.Echo.exe MyTestAssembly.dll "/f:exclude Category: Integration"
- Gallio.Echo.exe MyTestAssembly.dll "/f:include Type: MyFixture"
(here the "include" is optional)
- Gallio.Echo.exe MyTestAssembly.dll "/f:AuthorName: Jeff and Category: SmokeTests exclude Type: BrokenFixture, AnotherBrokenFixture exclude Importance: NoOneReallyCaresAbout"
TestDriven.Net Category Filters
As of v2.17, TestDriven.Net has a Visual Studio preferences page that allows the user to configure a couple of different settings.
In this update of Gallio we have added support for the TestDriven.Net category filter options. This feature was absent in previous releases because we did not then have a way to express exclusion filters properly.
New Assembly Version Numbering Scheme
Plug-in authors rejoice! I've changed how assembly version numbers are constructed in a subtle but important way.
Previously the assembly version number would change after each build. As a result, code linked to Gallio v184.108.40.2069 wouldn't work with Gallio v220.127.116.112 despite there being no significant API changes between those versions.
Now the last component of the assembly version number is always 0. This way there can be no assembly version conflicts within a given release branch. However, we still need a way to distinguish different builds. So the file version number contains the full version number.
For example, in this release the version numbers are set as follows:
- Assembly version: v18.104.22.168.
- File version: v22.214.171.1243.
As a result, you should no longer need to recompile your plug-ins except to make them work with a new release branch.
Aside: There is now a separate branch for Gallio and MbUnit v3.0.6 in case you want to check out the code and play with it. This will also help us keep maintenance updates on track.