xunit
Unable to run tests for Universal Class Library
This is very likely the common problem of project.json-based projects: dependencies aren't copied during build, so those things cannot be run by the traditional runners.
I also wouldn't expect R# to be able to run UWP test projects, since R# right now only runs desktop test projects. At best, it would run your tests in the desktop environment and not inside a UWP environment. To run unit tests in the UWP environment, I would strongly recommend using the xUnit.net Devices Runner (see the Getting Started page for more info).
Woah. I didn't know project.json projects didn't copy dependencies. That makes things interesting...
It started with DNX, which didn't copy anything (they have their own load context, so it's able to load the referenced assemblies from their cached location). I haven't spent any time with the dotnet CLI, so I don't know whether it continues with this behavior.
This behavior carried over into UWP when they adopted project.json, and at least as of Update 1, it still remains as the default behavior. Since their build process is intended to either generate NuGet packages or UWP app packages, copying the dependencies wasn't deemed to be a required step.
There is an MSBuild property value that you can use to get the copy-on-build behavior, if memory serves. @onovotny would know what it is.
dotnet CLI has their own loader as well, afaik, but it's different than DNX.
For project.json class libraries that need dependencies copied, you need to add CopyNuGetImplementations set to true to the csproj file. It automatically does that for appx/exe projects.
UWP test projects are actually applications, not class libraries. The main method/app class comes from the TestFramework stuff, not MSTest/xUnit/user's app directly.
Testing UWP is hard because the machinery that deploys the code, fires up the AppContainer, and sets up the IPC, is not documented...so the VS Addin works because it uses the TestFramework but we have no clue how we'd do it otherwise.
Outside of VS, I belive the vstest.exe command line uses the same machinery, but that's still undocumented about how you'd effectively create that yourself -- and that's really what's needed.
