What coding style is this code base going to enforce?

I couldn't find a consistent style when I was looking through the code. Ended up defaulting to dotnet org coding style because it was familiar. Willing to convert to whatever coding style is decided on though.

The status icon doesn't appear when the test consists of several test cases. Tests based on Inline or ClassData types don't update the status icon. Tests are performed and counted.

When one loads an assembly from the menu, and then tries to execute tests, the execution fails silently. No log file, no message, nothing.

After debugging the code, one finds that the full path of the assembly is lost in the test discovery, and then the worker tries to execute the assembly without the full path.

In addition, the diagnostic information generated by the worker in Console.Writeline, should be redirected to a file so that it can be read later. At present, it is silently lost.

This is helpful when writing a bunch of test cases that fail at first and fixing them afterwards.

It'd be nice to have releases so we didn't have to clone and build on every machine we want to use this on.

Hi everyone and thanks for the amazing project!

We forked this project to create a runner for Revit (architectural modelling software) and it's working great so far.
The issue we're having now is that, to implement CI pipelines, we're trying to spit out an xml results file that will be then read by Azure.

Does this runner do that?
I had a look at the code but couldn't really find anything, so I thought I'd ask in case I missed something. In case it doesn't, would you know what should I do and what xUnit APIs I should use to implement that?

Thanks!

Thoughts @dpoeschl @Pilchie ?

As much as I like building from source I think it would be nice if there was an auto-updating deplyoment option. Squirrel seems to be the new hotness here.

No license has been provided for the project. Can you clarify what license the source is under?

I need to work on a custom GUI for running xunit tests (internal to my company) and being able to reference this code would be quite helpful.

Cheers.

When trying to run a specific test, it actually tries to run all of them.

Today the only option is to discover / run unit tests on desktop. Need to also support via CoreClr.

This actually shouldn't be too much work given that the project already has a multi-process model.

The out of process support is functional now but the current design isn't going to work well for debugging unit tests. The current work flow is to create a new process per assembly per UI invocation of running tests. This makes attach pretty difficult from Visual Studio.

I think we need to move to a slightly different model for running tests. Essentially move the worker process into a more long term server role. Visual Studio can attach to this process and have a natural experience for debugging unit tests.

The xunit framework still uses AppDomain for isolating test runs so the process shouldn't lock the DLLs on disk once the run is completed.

If my tests run any native code in my project, the native libs cannot be overwritten until I kill the worker process. I'm not sure there's an easier solution, but I'm wondering if letting the worker process recycle itself if no debugger is attached and a certain timeout has elapsed. It would be a hack, but it's all I've got that would preserve the current debugging flow.

Other ideas? Happy to try to contribute a fix if we can come up with a good solution.

@jaredpar @Pilchie @DustinCampbell

Also, have it contain and msbuild props file that sets the StartupAction, etc for easier debugging.