If it behaves like a static object during tests but you need its values for settings I suggest refactoring code to need it injected, this will allow you to give either a “non persisted” real value, or a double with the same shape. This could even be memoized across the test suite.
If everything is hanging off it relationally this becomes a problem but all this test pain is doing here is exposing the complications that have arisen from this pattern of design. God objects are convenient but they often cause growing pains such as you are experiencing! I wish you luck :) Jon Rowe --------------------------- [email protected] jonrowe.co.uk On 21 August 2018 at 11:45, Uros Certic wrote: > Well it's a portal object and 99% of application functionalities rely on > portal existing with its settings. Portal is changeable but it is not changed > everywhere. My thought was that i always have that object in database and > just change portal settings in tests where it is needed since now i'm > inserting it before every test. Updating it on some places and reseting it > after is by my thought much better for performance than inserting it for each > test. > > > > > > -- You received this message because you are subscribed to the Google Groups "rspec" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/dejalu-192-84476a3e-0569-411c-92ca-85e6ea88e202%40jonrowe.co.uk. For more options, visit https://groups.google.com/d/optout.
