This project is read-only.

Tools

Sep 17, 2008 at 10:27 AM
Edited Sep 17, 2008 at 10:27 AM
For your information, there have been improvements on the TFS  and SVN front - see this: http://blogs.msdn.com/codeplex/archive/2008/09/14/codeplex-launches-support-for-tortoisesvn.aspx
Sep 17, 2008 at 10:30 AM
Edited Sep 17, 2008 at 2:40 PM
I have asked a question on Stackoverflow.com that may be relevant to testing the repository classes, in particular to using the same test suite on different repository implementations.
The answers may illuminate how we go about testing interfaces:

http://stackoverflow.com/questions/81317/using-the-same-test-suite-on-various-implementations-of-a-repository-interface
Sep 17, 2008 at 10:51 AM
SVN support is very cool and I guess will make it even easier for people to check-out the source. I've also been impressed with Visual Studio Team Explorer.
Sep 18, 2008 at 5:54 AM
great post on stackoverflow!  I like the base class option personally.
Sep 18, 2008 at 9:27 AM
I'm thinking of using the base class option to put some tests on all providers,
and if need be option 1 to put some tests against only some of the providers.
Sep 18, 2008 at 4:47 PM
+1 for the base class option :-)
Sep 18, 2008 at 11:48 PM
Done. Now we need to write some substantial tests, and to make them pass.
And maybe set up some File-based providers (and file data for them) to feed to the same tests
Sep 19, 2008 at 6:19 AM
Can you explain the need for the type enum?  I think we can avoid it. So, as an example I added a categories test which uses a base constructor to set the repository with less code.
Sep 19, 2008 at 9:21 AM
The RepositoryType enum can be thought of as the "mode" of the tests, or a flag to tell the tests how to operate.
I'm sure that it can be done without the enum, but the enum seemed to me the simplest way to do it.
The stack overflow answers mention it: http://stackoverflow.com/questions/81317/using-the-same-test-suite-on-various-implementations-of-a-repository-interface

You could create the test class with a new repository, but there are lifecycle issues - with the File or SQL repository, you sometimes want to test that the data has been persisted - e.g. create a repository object, save data using it, then create a new repository object (in the same test), and try to load the same data back.

With the mock repository, you can see that the GetRepository() method creates one Repository instance and returns it repeatedly. This is because there is no "back end", the data is stored in memory in the instance.

Another way to do it - perhaps the constructor could be given a "generator function" or anon delegate that creates repositories on demand.


Sep 19, 2008 at 2:09 PM
Sounds like an abstract GetRepository method on the base class is all that is needed.  I could be trying to oversimplify things though.
Sep 19, 2008 at 3:41 PM
Edited Sep 19, 2008 at 8:43 PM
That would actually work nicely - I didn't spot the simpler way. I will do it that way.