RSpec allows users to share context across tests / examples, which would reduce the number of code lines in my app by a significant amount.
On the other hand, somehow related to the question of sharing codebase between tests, one of the reasons why I’m using Factories and not Fixtures is because I don’t want tests to be dependent on code stored outside the tests. Ryan Bates explains it better:
There’s a heavy dependency between the tests and the fixtures and we can cause the tests to fail just by changing the fixtures. External dependencies that are this strong aren’t a good idea and make the tests brittle.
What’s best practice here, to share context across tests or to have an independent context for each test?
3
The factory in of itself is supposed to seem stateless, in that from the caller point of view, the factory does the same thing each and every time. So logically, the only way you could present a problem sharing a factory is if you somehow breached this contract and returned instances were somehow affected by previous calls to the factory.
In other words, a factory can and usually does perform optimizations for creating instances, but the caller can’t be at all affected by this. So in the simple case in which a factory merely creates an instance and returns it would not cause you problems which you would have to worry about with a shared factory.
However, while a factory can optimize this by sharing instances, it’s understood that the objects being shared are (or seemingly) stateless. If they are not and if you are lucky, you see these errors immediately, though if you’re not lucky, then you receive a series of bugs in your program that may not present themselves until many months later. This is an anti-pattern and if I may add, a particularly nasty one.
So if you want to use a factory, just be sure it fits the pattern. If you’re not dealing with stateless objects, just don’t take any shortcuts and instantiate each object when the factory is called to create an instance and you should be fine.