I am trying to implement the repository pattern with my tests so that I can save and review all test information at a later point. So far I have a shell of what I need to do but as of now I am stuck on where to go from here. So far I have my interfaces page, repository page done and my actual tests.

Here is what I have so far:

Interfaces page:

 internal interface ITestRepository
        void Save(string Case, DateTime dateTime, bool DidPass, object req, object res);

        void Save(string artifact);

And here is my repo page.
Now I know those two pages have to communicate with each other and the actual tests to work. But I am stuck on how to go about that and tutorials online are really vague and don't get deep enough for me to fully understand.

public class FileRepository : ITestRepository

        public void Save(string Case, DateTime dateTime, bool DidPass, object req, object resp)

        public void Save(string artifact)
3 Years
Discussion Span
Last Post by Ketsuekiame

Could you clarify what exactly you want to do next? There are many many paths you could follow from here. Typically, you haven't implemented a "Get" or a "Set" or any type of persistance/caching mechanism. You also need to consider Serialisation and whether or not you will store your data in Binary or Human Readable (XML?)

There's many things to consider, so you need to decide what exactly your next goal is. (Don't think too big)


Basically I want to be able to run a series of tests and then run the repository in those tests to extract that data as they run and storing them in an XML is ideal. For example, in the test I would get the ID number in the response and hopefully be able to have that also appear in the xml repo.

So I guess my next goal is to figure out how exactly to properly make my interface page then make the repo page to correspond. Any useful sites or ideas on how to go about this? I can also show what I have if you need additional information.


I think you're getting a lot of terms and patterns confused and jumbled together.

Treat each system in isolation and ensure that you have distinctive "layers" in your application.

You mentioned services and pages and repos.

So the repo would be your Data Access layer. This will be interacted with by the Service layer. The user will comunnicate using your User Interface layer.

So importantly, design your data access layer so that you can Create, Update, Delete. Also, it should internally handle saving the data to file/database/memory.

As a completely separate entity, you should be able to create your services. These will be more like that operations you want the user to perform. An example might be, "Open new Casefile". At this point your service will call your data access layer, request a new casefile object be created and then return this object. Note that your service layer should not care who called it. Just return the data requested.

The UI layer is how your user will communicate with the service. This could be as simple as pushing a "New" button.

It is important that no layer has knowledge of any other layer. This is why interfaces are so great.

I suggest that you concentrate on one layer at a time. This will prevent you accidentally adding "cross-knowledge" into your program.

So it seems you've started your DA layer, so let's finish that first. Decide where you want to store your data. You mentioned XML, so I assume you'll use file based storage. One problem with XML and file based storage is that it will be very slow compared to using a database, however, using file storage is pretty simple.

I suggest you Google how to use XDocument, XPath and XmlWriter. Additionally, you could look up StreamReader and StreamWriter if you wanted to go to a lower level.

Note: Casefile has nothing to do with the application, it's just an example of the types of object you might store.


Thanks for that info. Do you know of any sites that have any good examples of this?


sorry, the overall implementation of possibly saving data to an xml file. I created another class that will serialize data to an xml file and I just tested with dummy data and it works. But how does my "repo" class (if I am using the right term) know that it is taking data from my test classes? I understand that it works with the interface class and it is, but how does it work with the test class to obtain each of those values each time the set of tests is ran?


You create a Test class that implements the interface then you just create one of those instead of your live version.

Are you using the built in Unit tests?

You will also need to utilise the IoC (Inversion of Control) pattern so that you can change what data access model you're using.

At a basic level, it simply means having your repo constructor take an interface to your data access class. Then when testing, when you instantiate the repo then you pass in your test object, otherwise, you would pass in your live object.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.