Here's the updated proposal for PersistentMockRepository with the
feedback incorporated.
--Karl
p.s., Fabian/Patrick, thanks for your help and guidance!
p.p.s., MbUnit can't run/debug the PersistentMockRepositoryTests with
Resharper. I had to switch to NUnit2.4.1 to develop the unit tests.
For example, here's just one of many problems encountered:
"The process cannot access the file 'C:\Program Files\JetBrains
\ReSharper\v3.1\vs8.0\Bin\DevExpress.Data.v7.1.dll' because it is
being used by another process."
/// <summary>
/// PersistentMockRepository extends MockRepository with the
capability
/// to generate persistent assemblies for mock objects that change
rarely.
/// </summary>
public class PersistentMockRepository : MockRepository
{
/// <summary>
/// Return the singleton PersistentMockRepository, loading it from a
previously
/// saved assembly if present.
/// <see cref="m_IsAssemblyLoadedFromCache"/>
/// </summary>
public static PersistentMockRepository GetInstance {get; }
/// <summary>
/// Save the currently compiled assembly for re-use as an assembly
with the
/// returned path name (e.g., "{some path}/CastleDynProxy2.dll").
This call can
/// only be executed ONCE.
/// </summary>
public string SaveAssembly() ...
/// <summary>
/// Attempt to delete the cached assembly and return true if the
cached assembly
/// was indeed found and deleted.
/// </summary>
/// <returns></returns>
public static bool DeleteAssembly() ...
/// <summary>
/// Return true if this assembly was loaded from the location
/// specified by a previous call to SaveAssembly. A
PersistentMockRepository
/// that has been loaded cannot be extended to create proxies that
are not
/// contained within the loaded assembly (i.e., a loaded
PersistentMockRepostiory
/// is frozen.)
/// </summary>
public bool IsAssemblyLoadedFromCache {get;}
/// <summary>
/// Return file path to be used for cached assembly
/// </summary>
/// <returns></returns>
public static string CachedAssemblyFilePath {get;}
/// <summary>
/// Returns path to cache metadata xml file which is used to
determine
/// timestamps of referenced assemblies in order to invalidate the
cache
/// when they change.
/// </summary>
public static string PersistentMockRepositoryXmlPath {get;}
> Here's the updated proposal for PersistentMockRepository with the > feedback incorporated.
> --Karl
> p.s., Fabian/Patrick, thanks for your help and guidance! > p.p.s., MbUnit can't run/debug the PersistentMockRepositoryTests with > Resharper. I had to switch to NUnit2.4.1 to develop the unit tests. > For example, here's just one of many problems encountered: > "The process cannot access the file 'C:\Program Files\JetBrains > \ReSharper\v3.1\vs8.0\Bin\DevExpress.Data.v7.1.dll' because it is > being used by another process."
> /// <summary> > /// PersistentMockRepository extends MockRepository with the > capability > /// to generate persistent assemblies for mock objects that change > rarely. > /// </summary> > public class PersistentMockRepository : MockRepository > { > /// <summary> > /// Return the singleton PersistentMockRepository, loading it from > a > previously > /// saved assembly if present. > /// <see cref="m_IsAssemblyLoadedFromCache"/> > /// </summary> > public static PersistentMockRepository GetInstance {get; }
> /// <summary> > /// Save the currently compiled assembly for re-use as an assembly > with the > /// returned path name (e.g., "{some path}/CastleDynProxy2.dll"). > This call can > /// only be executed ONCE. > /// </summary> > public string SaveAssembly() ...
> /// <summary> > /// Attempt to delete the cached assembly and return true if the > cached assembly > /// was indeed found and deleted. > /// </summary> > /// <returns></returns> > public static bool DeleteAssembly() ...
> /// <summary> > /// Return true if this assembly was loaded from the location > /// specified by a previous call to SaveAssembly. A > PersistentMockRepository > /// that has been loaded cannot be extended to create proxies that > are not > /// contained within the loaded assembly (i.e., a loaded > PersistentMockRepostiory > /// is frozen.) > /// </summary> > public bool IsAssemblyLoadedFromCache {get;}
> /// <summary> > /// Return file path to be used for cached assembly > /// </summary> > /// <returns></returns> > public static string CachedAssemblyFilePath {get;}
> /// <summary> > /// Returns path to cache metadata xml file which is used to > determine > /// timestamps of referenced assemblies in order to invalidate the > cache > /// when they change. > /// </summary> > public static string PersistentMockRepositoryXmlPath {get;}
Well, yes and no. Regarding client usage, I think that there are no
external dependencies or special actions. However, one issue to
consider is that building Rhino will now require NUnit 2.4.1 as well
as MBUnit. I believe we can simply add an NUnit.2.4.1 directory to
SharedLibs to address this new requirement.
Today I will integrate the updated RhinoMocks into our own application
production code unit tests to evaluate the new
PersistentMockRepository api and implementation. Stay tuned!
> > Here's the updated proposal for PersistentMockRepository with the
> > feedback incorporated.
> > --Karl
> > p.s., Fabian/Patrick, thanks for your help and guidance!
> > p.p.s., MbUnit can't run/debug the PersistentMockRepositoryTests with
> > Resharper. I had to switch to NUnit2.4.1 to develop the unit tests.
> > For example, here's just one of many problems encountered:
> > "The process cannot access the file 'C:\Program Files\JetBrains
> > \ReSharper\v3.1\vs8.0\Bin\DevExpress.Data.v7.1.dll' because it is
> > being used by another process."
> > /// <summary>
> > /// PersistentMockRepository extends MockRepository with the
> > capability
> > /// to generate persistent assemblies for mock objects that change
> > rarely.
> > /// </summary>
> > public class PersistentMockRepository : MockRepository
> > {
> > /// <summary>
> > /// Return the singleton PersistentMockRepository, loading it from
> > a
> > previously
> > /// saved assembly if present.
> > /// <see cref="m_IsAssemblyLoadedFromCache"/>
> > /// </summary>
> > public static PersistentMockRepository GetInstance {get; }
> > /// <summary>
> > /// Save the currently compiled assembly for re-use as an assembly
> > with the
> > /// returned path name (e.g., "{some path}/CastleDynProxy2.dll").
> > This call can
> > /// only be executed ONCE.
> > /// </summary>
> > public string SaveAssembly() ...
> > /// <summary>
> > /// Attempt to delete the cached assembly and return true if the
> > cached assembly
> > /// was indeed found and deleted.
> > /// </summary>
> > /// <returns></returns>
> > public static bool DeleteAssembly() ...
> > /// <summary>
> > /// Return true if this assembly was loaded from the location
> > /// specified by a previous call to SaveAssembly. A
> > PersistentMockRepository
> > /// that has been loaded cannot be extended to create proxies that
> > are not
> > /// contained within the loaded assembly (i.e., a loaded
> > PersistentMockRepostiory
> > /// is frozen.)
> > /// </summary>
> > public bool IsAssemblyLoadedFromCache {get;}
> > /// <summary>
> > /// Return file path to be used for cached assembly
> > /// </summary>
> > /// <returns></returns>
> > public static string CachedAssemblyFilePath {get;}
> > /// <summary>
> > /// Returns path to cache metadata xml file which is used to
> > determine
> > /// timestamps of referenced assemblies in order to invalidate the
> > cache
> > /// when they change.
> > /// </summary>
> > public static string PersistentMockRepositoryXmlPath {get;}- Hide quoted text -
In general, Rhino Mocks cannot have a dependency on a testing framework. The _tests_ can do whatever they want, but the Rhino.Mocks.dll assumes only CLR 2.0
I'll look at the patches in detail in the next few days, no time at the moment
> Well, yes and no. Regarding client usage, I think that there are no > external dependencies or special actions. However, one issue to > consider is that building Rhino will now require NUnit 2.4.1 as well > as MBUnit. I believe we can simply add an NUnit.2.4.1 directory to > SharedLibs to address this new requirement.
> Today I will integrate the updated RhinoMocks into our own application > production code unit tests to evaluate the new > PersistentMockRepository api and implementation. Stay tuned!
> On Feb 16, 12:20 am, "Ayende Rahien" <aye...@ayende.com> wrote: > > Do I need to do anything special (aside from using the persistent mock > > repository to use it?
> > On 2/16/08, Karl Lew <well...@gmail.com> wrote:
> > > Oren,
> > > Here's the updated proposal for PersistentMockRepository with the > > > feedback incorporated.
> > > --Karl
> > > p.s., Fabian/Patrick, thanks for your help and guidance! > > > p.p.s., MbUnit can't run/debug the PersistentMockRepositoryTests with > > > Resharper. I had to switch to NUnit2.4.1 to develop the unit tests. > > > For example, here's just one of many problems encountered: > > > "The process cannot access the file 'C:\Program Files\JetBrains > > > \ReSharper\v3.1\vs8.0\Bin\DevExpress.Data.v7.1.dll' because it is > > > being used by another process."
> > > /// <summary> > > > /// PersistentMockRepository extends MockRepository with the > > > capability > > > /// to generate persistent assemblies for mock objects that change > > > rarely. > > > /// </summary> > > > public class PersistentMockRepository : MockRepository > > > { > > > /// <summary> > > > /// Return the singleton PersistentMockRepository, loading it > from > > > a > > > previously > > > /// saved assembly if present. > > > /// <see cref="m_IsAssemblyLoadedFromCache"/> > > > /// </summary> > > > public static PersistentMockRepository GetInstance {get; }
> > > /// <summary> > > > /// Save the currently compiled assembly for re-use as an > assembly > > > with the > > > /// returned path name (e.g., "{some > path}/CastleDynProxy2.dll"). > > > This call can > > > /// only be executed ONCE. > > > /// </summary> > > > public string SaveAssembly() ...
> > > /// <summary> > > > /// Attempt to delete the cached assembly and return true if > the > > > cached assembly > > > /// was indeed found and deleted. > > > /// </summary> > > > /// <returns></returns> > > > public static bool DeleteAssembly() ...
> > > /// <summary> > > > /// Return true if this assembly was loaded from the location > > > /// specified by a previous call to SaveAssembly. A > > > PersistentMockRepository > > > /// that has been loaded cannot be extended to create proxies > that > > > are not > > > /// contained within the loaded assembly (i.e., a loaded > > > PersistentMockRepostiory > > > /// is frozen.) > > > /// </summary> > > > public bool IsAssemblyLoadedFromCache {get;}
> > > /// <summary> > > > /// Return file path to be used for cached assembly > > > /// </summary> > > > /// <returns></returns> > > > public static string CachedAssemblyFilePath {get;}
> > > /// <summary> > > > /// Returns path to cache metadata xml file which is used to > > > determine > > > /// timestamps of referenced assemblies in order to invalidate > the > > > cache > > > /// when they change. > > > /// </summary> > > > public static string PersistentMockRepositoryXmlPath {get;}- > Hide quoted text -
On Feb 18, 4:08 pm, "Ayende Rahien" <aye...@ayende.com> wrote:
> In general, Rhino Mocks cannot have a dependency on a testing framework.
> The _tests_ can do whatever they want, but the Rhino.Mocks.dll assumes only
> CLR 2.0
Absolutely. We only require a change to the Rhino.Mocks.Tests 2.0
project. The production Rhino.Mocks is untouched and has no dependency
on nunit.
Initial tests with our application are promising. We are actually able
to debug our unit tests without crashing MSVS2005!!! WOOHOO!!!
This is a tremendous win for us and frees us from having to debug unit
tests by using WriteLine() statements.
8) Karl
p.s. A prerequisite for PersistentMockRepository is Castle-trunk 4800
with Fabian's changes. Although I could attempt to update the Rhino
trunk with Castle-trunk 4800, I'm nervous about doing that myself and
afraid I'd botch it. Would you mind doing that?
On Tue, Feb 19, 2008 at 3:32 AM, Karl Lew <well...@gmail.com> wrote:
> On Feb 18, 4:08 pm, "Ayende Rahien" <aye...@ayende.com> wrote: > > In general, Rhino Mocks cannot have a dependency on a testing framework. > > The _tests_ can do whatever they want, but the Rhino.Mocks.dll assumes > only > > CLR 2.0
> Absolutely. We only require a change to the Rhino.Mocks.Tests 2.0 > project. The production Rhino.Mocks is untouched and has no dependency > on nunit.
> I've updated the wiki with information on PersistentMockRepository:
> Initial tests with our application are promising. We are actually able > to debug our unit tests without crashing MSVS2005!!! WOOHOO!!! > This is a tremendous win for us and frees us from having to debug unit > tests by using WriteLine() statements.
> 8) Karl
> p.s. A prerequisite for PersistentMockRepository is Castle-trunk 4800 > with Fabian's changes. Although I could attempt to update the Rhino > trunk with Castle-trunk 4800, I'm nervous about doing that myself and > afraid I'd botch it. Would you mind doing that?
On Sun, May 4, 2008 at 1:56 AM, Ayende Rahien <aye...@ayende.com> wrote: > I am pretty ashamed of myself, for letting this lie aside for so long.Reviewed > and committed, thanks
> On Tue, Feb 19, 2008 at 3:32 AM, Karl Lew <well...@gmail.com> wrote:
>> On Feb 18, 4:08 pm, "Ayende Rahien" <aye...@ayende.com> wrote: >> > In general, Rhino Mocks cannot have a dependency on a testing framework. >> > The _tests_ can do whatever they want, but the Rhino.Mocks.dll assumes >> only >> > CLR 2.0
>> Absolutely. We only require a change to the Rhino.Mocks.Tests 2.0 >> project. The production Rhino.Mocks is untouched and has no dependency >> on nunit.
>> I've updated the wiki with information on PersistentMockRepository:
>> Initial tests with our application are promising. We are actually able >> to debug our unit tests without crashing MSVS2005!!! WOOHOO!!! >> This is a tremendous win for us and frees us from having to debug unit >> tests by using WriteLine() statements.
>> 8) Karl
>> p.s. A prerequisite for PersistentMockRepository is Castle-trunk 4800 >> with Fabian's changes. Although I could attempt to update the Rhino >> trunk with Castle-trunk 4800, I'm nervous about doing that myself and >> afraid I'd botch it. Would you mind doing that?
