Our tests are a bit of a mess in general, but there are some specific ways that they're a mess which I finally put a finger on yesterday. The "test" backend we provide is in some cases treated/used as an actual pseudo-backend, intended to exercise and ensure proper behavior within the core API. This itself is good. At other times, it's used as a source of "stubs," intended to act as filler when testing other, real behaviors. This is, itself, also good. But conflating the two isn't so good.

The simplest way to delineate between the two is that "test" stuff should be basically useless to any backend-specific tests (of which we need many MANY more), but "stub" stuff should be quite handy as a way of building objects to pass around that satisfy interfaces without having to fake much data. So I want a versioncontrol_stub.module to complement the versioncontrol_test.module The stubs should always be loaded, regardless of what's in $this->useBackends, whereas the test backend remains optional.

I realize that this is all still a bit of a murky distinction, and that there is a lot of overlap, but I'm confident that separating the two will make for clearer and better tests.

Comments

marvil07’s picture

marvil07 commented

I am confused here. By stub I think you are referring to VersioncontrolTestCase::versioncontrolCreate<entity> methods, and I do not see why it matters to not load it, it's just a little more memory.

In the other side, for backend specific tests, The backend could overwrite those methods.

I mean, I do not get why you want to put "stub stuff" on a module.

sdboyer’s picture

sdboyer commented
Status: Active » Closed (won't fix)

on further reflection, i think this is too pedantic and not really necessary. we can deal with it later.