Hey Ivan,
On 5 Feb 2018 11:18, "Ivan Enderlin" <ivan.ender...@hoa-project.net> wrote:
Hello :-),
Thank you for the RFC. I really appreciate it, for sure, but I would like
to raise a concern regarding the atoum test framework [1].
atoum provides 3 mock engines, resp. for class-like entitites, functions,
and constants.
The function and constant mock engines are both based on the same
principle, i.e. it relies on the “entity bubble look up resolution”
algorithm to mock functions or constants. Typically, one might mock the
`file_exists` function like this: `$this->function->file_exists = function
(…) { … };`. In this case, atoum creates a new `file_exists` function in
the same namespace than the system under test (if testing `A\B\C`, then
atoum creates `A\B\file_exists`).
It is a very convinient and beloved way to mock functions and constants.
And thus, this RFC raises the following issue: *This feature is used a lot
by atoum users. The RFC will destroy this feature. It's not about atoum
loosing a master feature, it's more about: How users will be able to mock
functions and constants after that? This is an important question*.
That's a hard question to answer, I know, but in its actual form, the RFC
breaks a non-negligeable part of the testing ecosystem. This is something
to take into account :-).
It is still possible to use moles instead of mocks to achieve the same
behavior, but restricted to user-defined functions only. Moles do not allow
to change the behavior of “VM-defined” functions.
Regards.
[1] http://atoum.org/
See https://externals.io/message/101745#101752
The problem is always with routines (not functions)) that rely on shared
global mutable state.
Mocking those is generally a problem, as it exposes a dependency inversion
issue, rather than actually getting rid of an implicit reliance on global
state that is not declared to consumers of a SUT.
