Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
[1] Allow setting the title of a unit test
[2] Handle the nesting logic while building the tests (get rid of the use of CanMergeWithParent, which is only used in TestNodeBuilder)
|
|
|
|
|
|
|
|
|
|
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1042673/
|
|
Add period to the template description.
|
|
Add period to the template description.
|
|
|
|
Support assemblies should always be used if they have already
been loaded.
Fixes UI tests when running locally.
|
|
|
|
* Fixes VSTS Bug 715151: [Feedback] 64 bit unit testing is not supported
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/715151
Unit testing now values the platfom target setting.
* [UnitTests] Improved API for the process architecture specification.
This can now used by other components as well.
|
|
The old autotools build infrastructure is largely redundant,
as projects are now built with msbuild. Remove as much as can
be done easily, along with some other obsolete stuff.
|
|
NuGet's PrivateAssets="runtime" does not work, resulting in transitive
references local copying their assemblies into every project. This
works around that by filtering out all local copies that are not
explictly listed.
This also makes it much harder to accidentally introduce local copies,
which is good as local copies in general are are not desirable due to
the way that dlls are loaded by the extension system.
|
|
|
|
|
|
These all have some kind of custom NuGet asset copying step
that will require additional logic.
|
|
|
|
|
|
Introduced a new ID which is clearer the source code connection ID.
|
|
|
|
The current logic for `IsSupportAssembly` doesn't take into account PackageReference binaries quite well since it cannot accurately determine with the availble information if such a reference will end up being copied to the output directory or not. This causes a lot of assemblies to be loaded in the running process mistakenly which in our case cause AssemblyLoad errors to happen.
This commit adds a workaround for now in the form of a project configuration option (set as a .csproj MSBuild property) to disable the current logic and essentially count on the fact that the necessary dependency closure for the tests are already being properly copied out by the build logic.
|
|
unit-tests execution
Test suite usually expects the working directory to be the path of the test assembly.
|
|
|
|
|
|
the text editor. No dot next to it.
TODO: Merge interfaces in the next AP break.
|
|
The NUnit3 test runner was being created with the filename:
NUnit3Runner.exe instead of NUnitRunner.exe so the IDE test runner
would fail to start this process. Changed the assembly name to
NUnitRunner.
Fixes VSTS #645844 - NUnit 3 integration broken because of misnamed
runner
|
|
|
|
Remove redundant information, and make more information
redundant by setting good defaults in the MD props.
This lays some groundwork for the PackageConfig migration
and eventually SDK-style project format migration.
|
|
|
|
|
|
|
|
They are most likely reference assemblies and will not load
|
|
|
|
The problem was that the NUnit test provider was finding a
PackageReference for NUnit, trying to load the tests for the .NET Core
project and failing. To fix this the NUnit test provider now ignores
.NET Core projects so the VS Test provider has a chance to load the
tests.
Fixes VSTS #565933
|
|
When a test used an Ignore attribute the Unit Tests window would
show a load error for the entire project and prevent any tests from
being run. The problem was that the load error check was looking for
a _SKIPREASON property on every test-suite xml element in the xml
produced by NUnit v3. When an Ignore attribute is used the xml has a
_SKIPREASON property for the test case and that was being found and
treated as an error. To avoid this only a test-suite xml element that
has a type of Assembly and has a runstate of NotRunnable is checked
for a _SKIPREASON.
VSTS 544671
|
|
The Unit Tests window would not show any unit tests when the project
contained an NUnit PackageReference. The NUnit addin was looking
for a PackageReference that contained 'nunit.framework'. Now a
check is made for 'nunit' instead.
VSTS 536137
|
|
After a load error occurs the Unit Tests window displays an error
icon and an error tooltip. After fixing the load error the error
icon and tooltip would not be removed from the Unit Tests window
until after the project was closed and re-opened.
|
|
collections.
|
|
This commits changes the way dependencies of a test project are computed by relying on the MSBuild machinary instead of being limited to only the project model.
This fixes cases where assembly references are computed on the fly e.g. when custom `ReferencePath` are specified in the project so that `<Reference />` with no hint path are still resolved (something the old system would mistakenly think of as GAC assemblies).
The commits changes the API for gathering dependencies to be asynchronous and applies the same sort of filtering as before to only load dependencies that wouldn't be otherwise loaded.
An exception here is that facades are pulled in by the underlying call to `GetReferences` without a way to differentiate them from other references, that causes assembly load errors down the line which this commit works around that by wrapping the call in `InitSupportAssemblies` in a try/catch.
NB: The scenario that called for this fix is a MonoDevelop addin testsuite which has very specific considerations when it comes to assembly loading. Since that test-suite already uses a custom console runner (via vstool\mdtool) to execute unit-tests maybe it would be a good idea in general to also allow delegation of `GetTestInfo` to a custom runner as well.
|
|
* Unify all System.ValueTuple references to 4.4.0.
* Use the net40 System.ValueTuple.dll in net40 projects.
* Don't use a netstandard reference.
* Fix another reference.
* Bump md-addins.
|
|
Fixed reading external runner's error from xml data.
|
|
|
|
|
|
updating for project references
|
|
|
|
reference.IsValid
|