[Dotnetmock-commits] dotnetmock/docs SupportingDifferentTestingFrameworks.txt,1.5,1.6

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/dotnetmock/dotnetmock/docs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22985/docs

Modified Files:
	SupportingDifferentTestingFrameworks.txt 
Log Message:
- Updated testing framework docs to reflect Choy's changes
- Updated readme content for new version
- Filled out changelog

Index: SupportingDifferentTestingFrameworks.txt
===================================================================
RCS file: /cvsroot/dotnetmock/dotnetmock/docs/SupportingDifferentTestingFrameworks.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** SupportingDifferentTestingFrameworks.txt	17 Jun 2004 20:49:44 -0000	1.5
--- SupportingDifferentTestingFrameworks.txt	12 Feb 2005 18:49:03 -0000	1.6
***************
*** 5,40 ****
  -----

! Originally, DotNetMock used NUnit internally.  This proved to be a problem for projects using other testing frameworks, internal or external.  With the 0.5.0 release, DotNetMock now provides initial support for using alternate frameworks.

  How?
  ----

! Currently, DotNetMock ships with implementations for three testing frameworks, NUnit 2.1, csUnit, and MbUnit.  To use either of these frameworks, simply copy the corresponding assembly, either DotNetMock.NUnit.dll, DotNetMock.csUnitNamespace.dll, or DotNetMock.MbUnitNamespace.dll along with the usual DotNetMock assemblies:
! 
! * DotNetMock.dll
! * DotNetMock.Framework.dll
! * DotNetMock.Core.dll
! 
! to your library directory.
! 
! Then, you need to set two environment variables, DotNetMock_TestingComponent & DotNetMock_TestingAssembly.  These two variables will signal to DotNetMock which testing components to use. DotNetMock_TestingComponent signifies the class implementating the ITestFramework interface and DotNetMock_TestingAssembly represents the local assembly that contains that class. The values of these variables for the currently supported frameworks are:
! 
! For NUnit:
! DotNetMock_TestingComponent = "DotNetMock.NUnit.NUnitTestFramework"
! DotNetMock_TestingAssembly = "DotNetMock.NUnit"
! 
! For csUnit:
! DotNetMock_TestingComponent = "DotNetMock.csUnitNamespace.csUnitTestFramework"
! DotNetMock_TestingAssembly = "DotNetMock.csUnitNamespace"
! 
! For MbUnit:
! DotNetMock_TestingComponent = "DotNetMock.MbUnitNamespace.MbUnitTestFramework"
! DotNetMock_TestingAssembly = "DotNetMock.MbUnitNamespace"

! These environment variables will ensure that the correct instances for your framework will be created.

! If you want to use NUnit, you do NOT need to set any of these variables, as NUnit is the default and will be loaded as a last resort.

! This procedure might might be streamlined in the future, possibly loading classes as modules, instead of full blown assemblies.

  Why?
--- 5,22 ----
  -----

! Originally, DotNetMock used NUnit internally.  This proved to be a problem for projects using other testing frameworks, internal or external.  With the 0.7.4 release, DotNetMock now provides support for using alternate frameworks.

  How?
  ----

! Currently, DotNetMock ships with implementations for three testing frameworks, NUnit , csUnit, and MbUnit.  To use either of these frameworks, simply make sure the corresponding dll is found somewhere within the applications path.  This can either be the standard probing path for local dll's or in the GAC

! The framework will attempt to load a testing framrwork in the following order:

! * NUnit
! * MbUnit
! * csUnit

! So, even if you have a certain version of one of the above frameworks in your GAC, you can override the version loaded by placing the desired version in your local path.

  Why?
***************
*** 42,58 ****
  Answers to some questions:

- Q: Why environment variables, and not XXX ( XML configuration variables, Factories, switches, etc... )
- A: Because environment variables are the easiest to use in a library.  Since most test assemblies are testing class libraries, environment variables make it easy to load variable information.  Config files would work, but the information will end up having to be put into every .exe.config that calls DotNetMock, which would prove to be a hassle.
- 
  Q: I don't use either of the supported frameworks, so can I provide my own testing framework implementation?
! A: Yes, of course.  Simple create a class that implements the DotNetMock.Core.ITestFramework interface.  Then, make sure your compiled assembly can be found by DotNetMock, either in the GAC or in the same directory ( reccommended ).  Finally, make sure to set the two enviornment variables found above.

  Q: Your implementation of (csUnit|NUnit|MbUnit) doesn't support my favorite assertion.  Can this be added?
! A: Sure.  The original implementations were meant to provide DotNetMock with enough funtionality to work.  They are by no means feature complete.  So, any missing features can be added.  Simply drop me a line ( gc...@us... ) or make the changes yourself, and submit a patch to me.  

! Having said all that, it should be clear that only feature common across testing frameworks can be supported.  Framework specific features would break the general interfaces.  I might support both implementations in the future, however.

  Any other questions or support issues should be submitted to http://www.sourceforge.net/projects/dotnetmock

! --Griffin
! ( gc...@us... )
\ No newline at end of file
--- 24,37 ----
  Answers to some questions:

  Q: I don't use either of the supported frameworks, so can I provide my own testing framework implementation?
! A: Not at this time.  The only frameworks supported are the three above.  If you would like to use your own framework, drop the developers a line at dot...@li... and we will see what we can do.

  Q: Your implementation of (csUnit|NUnit|MbUnit) doesn't support my favorite assertion.  Can this be added?
! A: Sure.  The original implementations were meant to provide DotNetMock with enough funtionality to work.  They are by no means feature complete.  So, any missing features can be added.  Simply drop the developers a line ( dot...@li... ) or make the changes yourself, and submit a patch.  

! Having said all that, it should be clear that only feature common across testing frameworks can be supported.  Framework specific features would break the general interfaces.  We might support both implementations in the future, however.

  Any other questions or support issues should be submitted to http://www.sourceforge.net/projects/dotnetmock

! -- The DotNetMock Development team
! ( dot...@li... )
\ No newline at end of file