Dot Net Platform


Sister

JimShore and WardCunningham have added support for the Microsoft .NET platform. Go to DownloadNow to get the software.

Here are our first results.

We approached the effort as five stories, all of which we've now finished.

  • Parse -- done
  • Core Fixture -- done
  • Runners -- done
  • TypeAdapter -- done
  • Advanced Fixtures (reflection) -- done

Here we are right after the first results came in.

Notice the Java results on the left screen and the identical C# results on the right screen. Also notice how happy the authors appear.


Some things about C# that had to be considered in translation.

  • substring(start, end) in java vs. substring(start, length) in c#
  • all types obey object protocol so no need for so many variants of TypeAdapter
  • assemblies need "search path" to packages
  • straight-across port first, then exploit cool features of c#
  • fixture path of some form


C# stores all of its classes in "assemblies," which are files ending in .DLL. In order to use reflection to instantiate a class, you have to know which assembly the class is in. FIT dynamically instantiates fixture classes, so it has to know where to find the fixture's assembly.

Java is similar in that Java's classes are usually stored in .JAR files. But in Java, all the JAR files are specified in the CLASSPATH environment variable. C# doesn't have an equivalent to the CLASSPATH variable.

So in order to resolve this problem, I introduced a "fixture path" parameter to the C# test runners. The fixture path is a semicolon-separated list of directories. When asked to load an assembly, FIT-C# looks in all the .DLL files in all the directories on the fixture path.

To make life a little bit easier for new users, FIT-C# comes with a pre-populated fixture path that includes relative paths to all the common C# assembly locations: bin, build, bin\Debug, etc. -- JimShore


Caution: It is easy to get lots of copies of framework classes spread around in lots of DLLs. When these get out of sync you will start getting exceptions looking up fixtures. MarsTanumihardja explains ...

I figured out why we were failing on the cast to Fixture. The dll that the fit.ActionFixture was being loaded from was different from the dll that the exe was referencing; therefore the dynamically loaded fit assembly was different from the statically referenced fit assembly.

I moved all the relevant DLLs into the same directory where the exe was being executed from, and all worked well. I did have to make a change in the location of where the music.txt file was located.

ChetHendrickson and RonJeffries have had similar problems and report this solution ...

What we did this morning was to make sure that Visual Studio's projects were all pointing at the same FIT DLL. To do this we had to set CopyLocal to false in some of the projects in the solution. Then, in the startup parameters, we put the directory to which we were pointing as the first directory in the third parameter. (Is this the party to whom I am speaking?)


Resources

 

Last edited September 20, 2005
Return to WelcomeVisitors