Porting test projects to use xUnit rather than mstest

Sep 4, 2011 at 8:51 PM

I wanted to do what I could to help get tests running on mono. It looks like getting mstest to work outside of Windows is difficult so I am taking on the "monkey work" that is porting from mstest to xUnit. I've created a fork and am pushing up my ports as I go. Phil asked me to start this discussion.

Questions:

Is xUnit acceptable? 

Is there any build automation scripts/processes that need updating?

Also, forgive my Hg ignorance as I am used to Git.

Kevin Miller

Developer
Sep 4, 2011 at 9:42 PM

xUnit is fine by me. Here are the list of things that need to happen before we accept a pull request like this:

  • You need to recommend a replacement for the existing toolchain (i.e things that are all integrated in to vs today need to have an alternative, like test driven .net)
  • You need to make sure all build.cmd works locally and will work on our ci machine(s) (we can help with that)
  • When you're ready to merge with main, reply to this thread and have one of the nuget devs help out with that since you're new to hg (we've had people make mess of this before)

If you have any problems or questions just ask.

Developer
Sep 4, 2011 at 9:44 PM

Oh and please make sure you look at our coding guidelines

Coordinator
Sep 4, 2011 at 10:08 PM

And thanks for taking this on! J

Sep 4, 2011 at 10:26 PM
All done with the manual monkey labor. There were a few cavets I ran into along the way. The worst being TextContext usage and lack of a match in xUnit. See this commit's diff at line 1074 
Regarding your bullets. I shall answer with bullets. :)
  • Sorry you lost me regarding the Toolchain what are you looking for? Here is what I know. 
    • Test Driven works great as a test runner for xUnit. It is what I used. 
    • Don't you have build automation which automatically runs the tests? 
    • Can't we use some xUnit msbuild task thingy to run tests?
  • I can run build.cmd with success. (see note below)
  • Happy to get help with merging. I don't get how to branch sorry. I see the Pull Request link want me to make one of those?

Note: I had to jump through icky hoops to find get the fxCop build task thing going which took the following. Please tell me I missed the hand auto setup of this.

  1. Download the 700MB Windows SDK (really?!)
  2. Find and run fxCop installer. See that the msbuild task is not included with fxCop. 
  3. Google again. Find Brad's post. Google for a download of the task and find this dude's GitHub repo.
  4. Download his build and copy to the right place creating the correct directory path and finally run build.cmd.
Sep 7, 2011 at 10:20 PM
dfowler wrote:

xUnit is fine by me. Here are the list of things that need to happen before we accept a pull request like this:

  • You need to recommend a replacement for the existing toolchain (i.e things that are all integrated in to vs today need to have an alternative, like test driven .net)
  • You need to make sure all build.cmd works locally and will work on our ci machine(s) (we can help with that)
  • When you're ready to merge with main, reply to this thread and have one of the nuget devs help out with that since you're new to hg (we've had people make mess of this before)

If you have any problems or questions just ask.

Dave anything I can do to keep this moving forward?

Developer
Sep 7, 2011 at 10:25 PM

Sorry about the delay. If you're pretty much done with the conversion I can get one of our devs to take a look at your changes to see if anything fundamental needs to be changed on our end (ci machine etc.).

Sep 7, 2011 at 10:34 PM

What's the point of this change? I don't want to do xUnit.

Developer
Sep 7, 2011 at 10:40 PM

Why not? Do you have a specific reason? 

Coordinator
Sep 7, 2011 at 10:58 PM

Did you read the discussion? It makes it more accessible to more developers. 

David, I re-opened a bug for this: http://nuget.codeplex.com/workitem/22

Please assign it to the appropriate person to integrate our CI etc.

Sep 9, 2011 at 5:28 PM
haacked wrote:

Did you read the discussion? It makes it more accessible to more developers. 

David, I re-opened a bug for this: http://nuget.codeplex.com/workitem/22

Please assign it to the appropriate person to integrate our CI etc.

Just pulled from origin. Fixed up my fork and pushed it. I would love to not have to maintain this fork too long. Tests do get a lot of churn. 

My pull request is here. Please give me feedback and let me know what else needs doing.

http://nuget.codeplex.com/SourceControl/network/Forks/KevM/xunit/contribution/1488

Developer
Sep 9, 2011 at 10:41 PM

I'll get it merged in today eve. I was trying to investigate if there was a better way to do tests that depend on TestContext \ TestContext.TestDeploymentDir but it doesn't look like it.

Sep 9, 2011 at 10:45 PM
Edited Sep 9, 2011 at 10:54 PM

Regarding a better way to approximate TestContext.DeployDir... I was thinking about this and you could have an expected environment variable get set by the build automation. If that is set then use it otherwise do what I am doing.