On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <[email protected]>
wrote:

>
> 2016-10-28 18:58 GMT+02:00 Guillermo Polito <[email protected]>:
>
>> No, please, kernel test should have the fewer dependencies as possible!
>>
> I would say this dependency is needed.
>

You're somehow neglecting how difficult it is to build and maintain the
system as it is.

Because if Kernel packages are tested using mocks it means that to be able
to test the system we need to:
 - build bootstrap
 - load SUnit
 - load mocks
     - which will load probably a proxy framework
 - then, just then, we are able to load the tests

Then to know if the system is in a good state, we have to make the
assumption that (and I say make the assumption because we cannot test it
yet at this stage)
 - sunit is ok
 - the mock library is ok
 - and all the mock library dependencies are ok

It is too much for the kernel.

> And again i'll hold my position: whoever wants to load it can do it. There
>> is no need to put it there by default.
>>
> Do you know how much easier it would be to design and test FileSystem with
> mocks. Code and tests will be much better and simpler from the beginning.
> And I could said it about any package which provide abstractions.
>

> Now no project which is part of Pharo can use mocks for tests. So it is
> not question of loading it for own project. Pharo contributors can't use
> mocks.
>

That is not true. People can create mocks by hand. They do not require a
library for easing it. Maybe it is a bit more bureaucratic but it still
works.

Second, mocks are no silver bullet. they are alright to decouple and try to
test some parts of the system in isolation, but then you still need
integration tests to test how the different components add-up together.


>
> And there is another story. Imaging Ruby guys join Pharo development (not
> real story :)). Many years In Ruby people use mocks and "human should"
> assertions.
>

Ruby guys can load the library they prefer. And use it in their projects.
I'm no-one to forbid that, and actually I'd encourage it if that is what
they want.

And actually this is what they do in Ruby: if they want a library they load
it. Why in Pharo it cannot be the same for god's sake??

Most TDD evolution was from Ruby. I imaging their impression about Pharo
> "the best for TDD".
>

TDD is not about mocks. TDD is not about tests. TDD is about a way to
approach the design of an application. And what makes Pharo IMHO "the best
for TDD" are not mocks but the debugger and how we can develop applications
with it.


> And generally I would said we have quite bad tests in system. They are
> slow, they corrupt image. Mocks will help to improve this situation.
>

Yes, but that's not because we do not have mocks. That's because some part
of the system are not designed to be tested (depend on global state), or
because nobody cared of writing good tests.

**I am 100% sure that people can write bad tests with any mock library that
you want**

Reply via email to