How prepare input data for tests?

I had had a problem with preparing input data for tests. I am looking for the best way for it, because this is problematic. Why? I tell you something about it and my mistakes.

The ways which I tried

All in tests/suite

I want to tell you about my first solution. I read about good tests and I often read that on the tests should be prepared always only on a test or suite tests. This is a good point, because when I read these tests I know what I have in input. I shouldn't search information about it.

I think you agree with me that You have all on this place when you need to check why the test is failed.

Minuses are two in this solution. First is a lot of copy paste code. If you don't have a problem with duplicate code, you never refactor your code or change functionality. After these actions you always need fixes a lot of tests where you use that object. Sometimes you can use replace feature on your IDE, but when you create a product with other people, I am sure You will find a person who write the code a little different than you. This is the worst way in the changeable project. A small number of projects are durable, so I suggest won't use it. Second is you always must know how the objects should be created.

Create one context for all tests.

This is the idea for resolving a problem with refactoring and changeable models. If you have all in one place you must only change code in this. It is resolving the problem with knowledge about how objects should be created too. After creating objects in context, you can reusable it without knowing how the object was created. You can create a basic class for tests and only extends it or create a service which create that context for you. This is easy to implement and resize.

Do do think this is life trick for tests? I have to disappoint you. This is really problematic, because that context will be bigger and bigger. All tests must initialize it and it runs slower and slower. When you have 1 thousand tests that context is very unreadable, big and slow. I think that is the argument to throw it in the trash.

Fabrics

This is my actual idea for it. I don't try it on a big project, but on the theoretical this should be a good solution for that. I try it on my little application and it look good. The solution is that create the core fabric method for input data. If you want a person you use createPerson, but if you want person with access you use method createPersonWithAccess. I think this example shows you what I want to say. I think that these methods must be good created. The first important thing is creating all objects which depends on. We shouldn't create other objects on tests only for it. If you want to test a functionality like "a task for the project should be created" you want to create only object task, maybe sometimes project, but really not the owner of the project, company, tags and a lot of things whose are required.

I don't know how about you, but I see in this way something alike production code. I heard from one of my colleague at work (thanks for it) that we should create test code like production code. Maybe this is right and people, who say DRY on tests don't work, are wrong. I think so this is a good point to check and focus on it.

Fabric have advantages from one context too, and resolve the one context problems with speed, because you create only objects which you need, and size, because you create a lot of small fabric for specific domain objects and use it when you create depend objects.

Any other ideas?

I want to create a good practices for testing based on practice. If you have any idea how to create input data for tests feel free to put information about it below in the comment.