Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for UWP #322

Open
rprouse opened this issue May 5, 2017 · 14 comments
Open

Add support for UWP #322

rprouse opened this issue May 5, 2017 · 14 comments

Comments

@rprouse
Copy link
Member

@rprouse rprouse commented May 5, 2017

Now that the test adapter supports .NET Core, it should be fairly easy to add in UWP (Windows 10) support.

  • Add appx to the supported file formats
  • Add a UWP target to the multi-targeted adapter
  • Add UWP to the nuget package

I have notes in Evernote on everything that needs to be done, so assigning to myself.

@OsirisTerje

This comment has been minimized.

Copy link
Member

@OsirisTerje OsirisTerje commented Jul 5, 2017

@rprouse Any chance of getting this in before July 16th? (Current milestone), or perhaps within July (change milestone to 31th) ?
Or should we align with NUnit milestone for it's 3.8 version, which is August 31th ? Perhaps the best option?

@rprouse

This comment has been minimized.

Copy link
Member Author

@rprouse rprouse commented Jul 5, 2017

We have all the bits for the NUnit framework and most of the work is done for the .NET Core version of the engine, I just need to add an additional target there, an additional target for this project and then add the appx.

I would like to get it in, but it might be a good idea to push the milestone out a bit.

@CharliePoole

This comment has been minimized.

Copy link
Member

@CharliePoole CharliePoole commented Jul 5, 2017

@OsirisTerje I see that there are three items completed in the 3.8 milestone, two features and one important bug fix. Aside from this new major feature, you have one other with nobody assigned.

What advantage do you see in postponing the release, which has already (I think) been postponed once? There is a value in users getting releases at the time they are promised, just as there is a value in having brand new features.

As the project lead, the release philosophy for the adapter is pretty much up to you, but the open source maxim "Release early, release often" seems applicable here. It seems to me that the overhead of creating a release for the adapter is relatively low, compared to the framework or console/engine, so you could release as frequently as you like, with each release containing a relatively small number of enhancements and new features.

@rprouse

This comment has been minimized.

Copy link
Member Author

@rprouse rprouse commented Jul 5, 2017

@OsirisTerje I have been a bit rushed today, so I wanted to expand on my thinking. No framework changes are required for this and if I am right, only a few lines in the engine and adapter are needed to enable it. I've already done most of the work I just need to turn it on and test it. If it doesn't work as expected, then I think we should move this out of the 3.8 release.

I also don't think the release will need to be delayed, but I am open to moving it out because the console/engine is behind and I want to get that out first so the adapter can use the latest engine.

@OsirisTerje

This comment has been minimized.

Copy link
Member

@OsirisTerje OsirisTerje commented Jul 5, 2017

@CharliePoole Agree with the release often philosophy, but not too often - but 1.5 month in between should be fine. So, then better to ship it now, and another release with the new engine when that is ready. I'll create an issue to update the engine once that is ready, so we have something to tag it on.
I am aware of #323 and the corresponding #215, not really sure why #323 is into this milestone. And not quite sure how we should approach it, a logger extension is a separate extension, it could be baked into the adapter, but that doesn't sound right either.

@CharliePoole

This comment has been minimized.

Copy link
Member

@CharliePoole CharliePoole commented Jul 5, 2017

That seems reasonable.

@rprouse

This comment has been minimized.

Copy link
Member Author

@rprouse rprouse commented Jul 12, 2017

@OsirisTerje I am pulling this out of the milestone. Since I released an alpha of 3.8 with the .NET Core support, I think I should at least update the .NET Standard engine to non-alpha for the 3.8 release. I am planning on doing a console release this week, probably Thursday, so we should be able to get it in.

@OsirisTerje

This comment has been minimized.

Copy link
Member

@OsirisTerje OsirisTerje commented Sep 14, 2017

@rprouse I've added this into the 3.9 milestone, any chance of getting this in, or if you could share your notes?

@rprouse

This comment has been minimized.

Copy link
Member Author

@rprouse rprouse commented Sep 14, 2017

There are a number of unknowns here, especially now that we know that discovery will happen in the desktop version of the engine and execution will happen in the .NET Standard version of the engine.

A high level TODO for this is,

  1. Add the APPX (correct?) extension as supported to the framework driver in the engine. I originally thought that would only be for the .NET Standard, but I think it might also be required in the main engine for discovery. Will need to test.
  2. Add a UWP target to the NuGet package. This folder will include the same files as the .NET core folder plus a .targets file. Here is the xUnit version,
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="AddXunitTestAdapterLibs" AfterTargets="_ComputeAppxPackagePayload" BeforeTargets="_GenerateAppxManifest">
    <ItemGroup>
      <xUnitVsLibs Include="$(MSBuildThisFileDirectory)xunit.runner.visualstudio.uwp.dll">
        <TargetPath>xunit.runner.visualstudio.uwp.dll</TargetPath>
      </xUnitVsLibs>
      <xUnitVsLibs Include="$(MSBuildThisFileDirectory)xunit.runner.visualstudio.uwp.pri">
        <TargetPath>xunit.runner.visualstudio.uwp.pri</TargetPath>
      </xUnitVsLibs>
      <xUnitVsLibs Include="$(MSBuildThisFileDirectory)xunit.runner.utility.netstandard11.dll">
        <TargetPath>xunit.runner.utility.netstandard11.dll</TargetPath>
      </xUnitVsLibs>
      <xUnitVsLibsToRemove Include="@(AppxPackagePayload)" Condition="'%(TargetPath)' == 'xunit.runner.visualstudio.testadapter.dll'"/>
      <xUnitVsLibsToRemove Include="@(AppxPackagePayload)" Condition="'%(TargetPath)' == 'xunit.runner.utility.net35.dll'"/>
      <AppxPackagePayload Remove="@(xUnitVsLibsToRemove)" />
      <AppxPackagePayload Include="@(xUnitVsLibs)" />
    </ItemGroup>
  </Target>
</Project>

From there, we need to ensure that discovery works.

@OsirisTerje

This comment has been minimized.

Copy link
Member

@OsirisTerje OsirisTerje commented Feb 3, 2018

@rprouse Is this still in limbo? I'm working on getting out a 3.10 release. Should we push this issue further out?

@rprouse rprouse removed their assignment Feb 4, 2018
@rprouse

This comment has been minimized.

Copy link
Member Author

@rprouse rprouse commented Feb 4, 2018

I've taken my name off this, I haven't looked at it.

@Seikilos

This comment has been minimized.

Copy link

@Seikilos Seikilos commented Oct 18, 2018

What's with 3.11 ?
Release https://github.com/nunit/nunit/releases/tag/v3.11 states UWP support but are there any constraints on project type etc? R# does not detect NUnit tests for Universal Windows.

@rprouse

This comment has been minimized.

Copy link
Member Author

@rprouse rprouse commented Oct 21, 2018

That probably should have been clearer, it is the first step to allowing UWP support, but we still don't have a runner or adapter that supports it.

@mrlacey

This comment has been minimized.

Copy link

@mrlacey mrlacey commented Jan 29, 2019

Any idea on when, or if, this will ever happen?

I'm currently adding the ability to include unit test project creation as part of scaffolding a UWP app with Windows Template Studio. I'd wanted to include NUnit in this but am unable to because of this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.