It seems to me that there perhaps needs to be more clarity here ... I
think there is perhaps a difference in between "kernel tests should have
fewer depencies" and "mocks missing from Pharo".
Is "Pharo" and "kernel" synonymous?
I imagine that there is a minimal/minimum kernel image that has the
kernel and nothing else ... but this kernel image has very little in it
and may not even have bare bones development tools ...
I also imagine that there is at least one "Pharo minimal" image (perhaps
this is the "kernel" that Guille is referring to?) that is the minimum
kernel plus the bare minimum of development tools installed ... no bells
and whistles, or anything shiny ... this is the base image that
developers would use when they want to build an image aimed at their
specific needs ... and of course the image is the starting point for the
"developer image" ...
I also imagine that there is at least one "developer image" that is
targeted at developers and this image will be billed as the "recommended
developers image" and this image should come with the full suite of
development tools and supporting projects to make life easy for most
developers so that they don't have to customize their development
environment from the get-go.
I would think that maintaining the "developer image" would be not that
much more complicated than maintaining the 100 or so Contributor builds
--- it is built on top of the "Pharo minimal/kernel" image --- all the
tests are run, which is the most important thing...
Dale
On 10/28/2016 11:36 AM, Denis Kudriashov wrote:
2016-10-28 18:58 GMT+02:00 Guillermo Polito <[email protected]
<mailto:[email protected]>>:
No, please, kernel test should have the fewer dependencies as
possible!
I would say this dependency is needed.
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.
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. Most TDD evolution was from Ruby. I imaging their
impression about Pharo "the best for TDD".
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.
