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

AutoFixture.AutoFoq #56

Closed
ploeh opened this Issue Dec 30, 2012 · 28 comments

Comments

3 participants
@ploeh
Member

ploeh commented Dec 30, 2012

Would it make sense to write a glue library or auto-mocking extension for AutoFixture using Foq?

It would be similar to AutoFixture.AutoMoq or one of the other auto-mocking extensions, but better support unit tests in F# (at least better than Moq).

@ptrelford

This comment has been minimized.

ptrelford commented Dec 30, 2012

I like this idea, when you're writing unit tests in F# you'd have the expressiveness of AutoFixture with customizations for creating interface types, and access to Foq in the same package as required.

Let me know if you'd like me to expose a static method in Foq like Mock.Of : Type -> System.Object

@ploeh

This comment has been minimized.

Member

ploeh commented Dec 30, 2012

Maybe you'll get a pull request one day :)

Seriously, just to set expectations: I added this as a work item for a couple of reasons:

  • Personally, I have no time for this in the next couple of months, but I didn't want do forget about this idea
  • Someone else might decide taking on the challenge :)
@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Jun 17, 2013

I think, this one is currently the next queued item after we make some progress with #99 :)

@ptrelford I left a question on CodePlex :)

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Jun 23, 2013

@ploeh I was wondering if we should add FsUnit to source in order to use it from AutoFoqUnitTest project..

FsUnit looks quite mainstream when writing tests in F#.. On the other hand, besides AutoFoqUnitTest, I don't think it's going to be used from another AutoFixture unit test project (at least for the next couple of months)..

@ploeh

This comment has been minimized.

Member

ploeh commented Jun 23, 2013

I've used FsUnit in the past, and it's nice, but not a necessity. I think we should leave the decision to the implementer.

However, if we start adding NuGet packages as dependencies, perhaps we should first migrate all out dependencies to NuGet.

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Aug 16, 2013

I've slowly started implementing AutoFixture.AutoFoq.

Since I need to add Foq in the Lib folder I was wondering whether it's time to move to NuGet packages. What do you think? :)

I noticed though that xUnit.net in NuGet starts from version 1.7.0.1540 while we currently use 1.6.1..

@ploeh

This comment has been minimized.

Member

ploeh commented Aug 17, 2013

Now is as good a time as ever to move to NuGet.

If the lowest version of xUnit.net available on NuGet is 1.7.0.1540, we'll go with that. There's probably not a lot of people still relying on 1.6.1 any longer :)

This whole operation should, in my opinion, take place in a separate set of commits (not related to AutoFoq).

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Aug 23, 2013

I was thinking that the project(s) structure could be:

  • AutoFoq (C#)
  • AutoFoqUnitTest (C#)
  • AutoFoqUnitTest.FSharp (in order to verify that AutoFoq is usable from F#)

But then I though that it could be interesting to have the opposite:

  • AutoFoq (F#)
  • AutoFoqUnitTest (F#)
  • AutoFoqUnitTest.CSharp (in order to verify that AutoFoq is usable from C#)

In general, I was thinking that it could be possible to implement new AutoFixture glue libraries, extensions, etc in F#..

How does that sound? :)

@ploeh

This comment has been minimized.

Member

ploeh commented Aug 24, 2013

I like the second option best, although I'm not sure we need a C# unit test project at all. On the other hand, I'm not opposed to a C# unit test project either.

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 6, 2013

During the last couple of days I took the challenge and wrote AutoFoq entirely in F# :)

@ploeh, @ptrelford, any comments and/or suggestions are more than welcome.

Here is how the compiled assembly looks like in Reflector:

image

Note:
Since a new glue library is a fairly complex feature, according to the contribution guidelines we should first discuss about it here (on the issue page) and then decide if we should continue with a pull request.

@ploeh

This comment has been minimized.

Member

ploeh commented Sep 8, 2013

Overall, I think this is looking good, and that we should move ahead with it.

I do have some comments and questions, but I can't easily give those before this turns into a pull request.

@ploeh

This comment has been minimized.

Member

ploeh commented Sep 14, 2013

This has now been pushed out, but fails on the CI server with this error message:

D:\Builds\AutoFixture\Src\AutoFoq\AutoFoq.fsproj error MSB4057: The target "Build" does not exist in the project.
Project Src\AutoFoq\AutoFoq.fsproj failed.
D:\Builds\AutoFixture\Src\AutoFoqUnitTest\AutoFoqUnitTest.fsproj error MSB4057: The target "Build" does not exist in the project.
Project Src\AutoFoqUnitTest\AutoFoqUnitTest.fsproj failed.
Project Src\AutoFoq.sln failed.

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 14, 2013

I think I found.. by comparing side-by-side the AutoFoq.fsproj and Hyprlinkr.UnitTest.FSharp.fsproj:

image

As it looks like, this line is missing in AutoFoq.fsproj and AutoFoqUnitTest.fsproj:

<Import Project="$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" Condition=" Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')" />

FWIW, I used the F# compiler and tools that come with Visual Studio 2012.

@ploeh

This comment has been minimized.

Member

ploeh commented Sep 14, 2013

Hyprlinkr isn't on the CodeBetter TeamCity server - so far, Hyprlinkr changes so rarely that I didn't care to go through all the effort it is to set it up for CI.

I tried adding that line on both AutoFoq.fsproj and AutoFoqUnitTest.fsproj, but on my local machine, it now gives me these warnings:

C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoq\AutoFoq.fsproj(71,3): warning MSB4011: "C:\Program Files
(x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" cannot be imported again. It was already imported
at "C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoq\AutoFoq.fsproj (43,3)". This is most likely a build a
uthoring error. This subsequent import will be ignored.
C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoqUnitTest\AutoFoqUnitTest.fsproj(80,3): warning MSB4011: "
C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" cannot be imported again. It was
already imported at "C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoqUnitTest\AutoFoqUnitTest.fsproj (38,3)
". This is most likely a build authoring error. This subsequent import will be ignored.
C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoq\AutoFoq.fsproj(71,3): warning MSB4011: "C:\Program Files
(x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" cannot be imported again. It was already imported
at "C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoq\AutoFoq.fsproj (43,3)". This is most likely a build a
uthoring error. This subsequent import will be ignored.
C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoqUnitTest\AutoFoqUnitTest.fsproj(80,3): warning MSB4011: "
C:\Program Files (x86)\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" cannot be imported again. It was
already imported at "C:\Users\mark\documents\ploeh\Common\AutoFixture\Src\AutoFoqUnitTest\AutoFoqUnitTest.fsproj (38,3)
". This is most likely a build authoring error. This subsequent import will be ignored.

Before I tried inserting those lines in the .fsproj files, I had no local warnings.

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 14, 2013

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 15, 2013

error MSB4057: The target "Build" does not exist in the project

As it looks like from the error message, the F# build targets, the compiler, and the runtime are missing on the CI server..

If that's the case, we will have to reference F# from NuGet and also include the necessary build target file(s) in the source control.

@ploeh

This comment has been minimized.

Member

ploeh commented Sep 15, 2013

That is certainly one option, but perhaps we should contact the CodeBetter people to ask what their official position is on F# on their build agents...

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 15, 2013

OK, and in case there is no support for F# we could follow this sample I guess :)

@ploeh

This comment has been minimized.

Member

ploeh commented Sep 15, 2013

Right, but will you follow up with the CodeBetter team? I can also do that, but I'm really busy at the moment, so it may take longer if I have to drive it :$

Sorry about the inconvenience.

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 15, 2013

Yes, I can do that. No problem :)

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 18, 2013

As discussed here we could skip signing AutoFixture.AutoFoq.

After executing the BuildRelease.ps1 script I noticed (using sn.exe -vf) that the assemblies are not signed.

Does the signing happens as a separate build step on the CI server?

The signing happens on the CI server:

Command line parameters to MSBuild.exe: /p:SignAssembly=true /p:AssemblyOriginatorKeyFile=D:\Builds\AutoFixture\AutoFixture.snk

So perhaps including the:

<SignAssembly>false</SignAssembly>

in the AutoFoq.fsproj might skip the signing for AutoFixture.AutoFoq.

I will try it locally and see where it goes..

@ploeh

This comment has been minimized.

Member

ploeh commented Sep 18, 2013

Yes, signing happens on the CI server.

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 18, 2013

I just reproduced the error locally.

The /p:SignAssembly=true overrides the <SignAssembly> element (if exists) on each project file.

In order to sign all projects except AutoFixture.AutoFoq we need to:

  1. Exclude /p:SignAssembly=true from the command line parameters to MSBuild.exe.
  2. Include <SignAssembly>true</SignAssembly> to all project files except AutoFixture.AutoFoq.
  3. Include <SignAssembly>false</SignAssembly> to AutoFixture.AutoFoq and AutoFixture.AutoFoqUnitTest project files.
@ploeh

This comment has been minimized.

Member

ploeh commented Sep 18, 2013

If we include <SignAssembly>true</SignAssembly> in all project files exception the Foq files, isn't it going to give us build warnings locally when we don't supply a key file?

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 18, 2013

There are no warnings on my machine :)

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 18, 2013

There are no warnings but the assemblies should (somehow) reference to strong name key locally (which is currently on the CI server).

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 18, 2013

I think that #175 is the way to go.

The existing command line parameter to MSBuild.exe on the CI server should work fine:
/p:AssemblyOriginatorKeyFile=D:\Builds\AutoFixture\AutoFixture.snk

@moodmosaic

This comment has been minimized.

Member

moodmosaic commented Sep 19, 2013

It works :)

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment