Smalltalk › Pharo › Pharo Smalltalk Developers

Mocks are missing in Pharo (from thread OSProcess is missing)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

30 messages Options

Denis Kudriashov

Mocks are missing in Pharo (from thread OSProcess is missing)

We always said that smalltalk is the best for TDD.

But we not have mocks by default in Pharo while mocks is fundamental part of TDD.

So no kernel tests could benefit from them.

And more important TDD is design process and without mocks we can't apply it to kernel with full power.

What you think to integrate Mocketry in Pharo 6?

It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.

Best regards,

Denis

Guillermo Polito

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

No, please, kernel test should have the fewer dependencies as possible!

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.

Le 28 oct. 2016 18:52, "Denis Kudriashov" <[hidden email]> a écrit :

We always said that smalltalk is the best for TDD.
But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
So no kernel tests could benefit from them.
And more important TDD is design process and without mocks we can't apply it to kernel with full power.

What you think to integrate Mocketry in Pharo 6?
It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.

Best regards,
Denis

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-28 18:58 GMT+02:00 Guillermo Polito <[hidden email]>:

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.

Guillermo Polito

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

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

2016-10-28 18:58 GMT+02:00 Guillermo Polito <[hidden email]>:
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**

Esteban A. Maringolo

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-28 16:07 GMT-03:00 Guillermo Polito <[hidden email]>:
> On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <[hidden email]>
> wrote:

>> 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??

+1 to this. We should be able to deliver a minimal core, with the
basic features to load external packages.

The problem, I suspect, is that project discoverability/installation
might not be as straightforward as with a ruby gem, but the
integrated catalog eases that in a big extent.

Regards!

--
Esteban.

Dale Henrichs-3

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Denis Kudriashov

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 <[hidden email]>:

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.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Guillermo Polito

2016-10-28 21:07 GMT+02:00 Guillermo Polito <[hidden email]>:

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.

Come on, get real. It is not practical sentence. It is one of the reason of bad quality and amount of tests in system. People just not write tests when it is difficult. And building custom mock classes is supper slow and boring which moves you away from actual business problems.

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.

It is all valid and not against any of my point.

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 when Ruby guy will want to contribute to Pharo you will say him "build mocks by your hands". And he will say many nice words about TDD in Pharo.

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.

Exactly. We all know it. But look at system. Nothing is designed by TDD. Most tests are written after code. And most tests are high level acceptance tests.

And what makes Pharo IMHO "the best for TDD" are not mocks but the debugger and how we can develop applications with it.

As you said TDD is about design. First we specify design decisions in test. And only then we start implement them. So debugger is only about second part. And Pharo here is the best.

But writing specifications in tests is quite limited without advanced mock library. Limited in practical sense. It should be maximum simple technically: if your real object is hard to setup or you not have one then just get mock with minimal effort. Without it TDD process is always interrupted by non business problems.

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**

And I am 100% sure that people can write spaghetti code with any language that you want. Why use Smalltalk then?

P.S. nice post on TDD from Uncle Bob http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Guillermo Polito

2016-10-28 21:07 GMT+02:00 Guillermo Polito <[hidden email]>:

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

I am not.

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

So adding simple config is problem?

As you explain in last TechTalk all difficulties were related to managing dependencies between core packages which were tightly coupled and not designed with this in mind.

Mocketry defines all dependencies in config. It's just two projects: StateSpecs and Ghost. And they not require anybody else. (there are separate config groups for GT support).

It is too much for the kernel.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-29 0:12 GMT+02:00 Denis Kudriashov <[hidden email]>:

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

Actually I am not talk exactly about bootstrap kernel. I mean all system included in Pharo.

And while you are against bootstrap part what about the rest of system?

stepharo

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Denis Kudriashov

Denis

We are working since 4 years now to get

- have a small kernel + tests

- be able to load nicely configurations

We should not add something else than Sunit for tests of the small
kernels tests.

Now people can use whatever they want to test their system but for the core

we are really picky because loading on single package may add far too
many dependencies.

and it means

- more time to load

- more time to debug

- more time to just understand what did not work during the bootstrap.

So our goal is to shrink the minimal core and not to extend it. So we
will add mock by hand if we need them.

I agree with Guillermo. Far too much pain.

Stef

Le 28/10/16 à 18:51, Denis Kudriashov a écrit :

> We always said that smalltalk is the best for TDD.
> But we not have mocks by default in Pharo while mocks is fundamental
> part of TDD.
> So no kernel tests could benefit from them.
> And more important TDD is design process and without mocks we can't
> apply it to kernel with full power.
> What you think to integrate Mocketry in Pharo 6?
> It has comments and documentation (PharoInProgress, Help), advanced
> features and it is very competitive to any modern mock libraries.
>
> Best regards,
> Denis

Tudor Girba-2

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

Hi,

I actually think there is no disagreement in this discussion :). I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that:
- Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks.
- Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely.

From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features. However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside.

@Guille, Stef: Does this reflect what you think?
@Denis: Is this reasonable for you?

Cheers,
Doru

> On Oct 30, 2016, at 9:33 AM, stepharo <[hidden email]> wrote:
>
> Denis
>
> We are working since 4 years now to get
>
> - have a small kernel + tests
>
> - be able to load nicely configurations
>
> We should not add something else than Sunit for tests of the small kernels tests.
>
> Now people can use whatever they want to test their system but for the core
>
> we are really picky because loading on single package may add far too many dependencies.
>
> and it means
>
> - more time to load
>
> - more time to debug
>
> - more time to just understand what did not work during the bootstrap.
>
> So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them.
>
> I agree with Guillermo. Far too much pain.
>
> Stef
>
> Le 28/10/16 à 18:51, Denis Kudriashov a écrit :
>> We always said that smalltalk is the best for TDD.
>> But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
>> So no kernel tests could benefit from them.
>> And more important TDD is design process and without mocks we can't apply it to kernel with full power.
>> What you think to integrate Mocketry in Pharo 6?
>> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.
>>
>> Best regards,
>> Denis
>
>

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."

Nicolai Hess-3-2

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-30 11:41 GMT+01:00 Tudor Girba <[hidden email]>:

Hi,

I actually think there is no disagreement in this discussion :).

I am not sure about that.

I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that:
- Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks.
- Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely.

Denis wants to have a Mock-Framework to be used for SUnit, and if we have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to be in it too, no ?

From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features.

Feature freeze? Really, since when?

However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside.

@Guille, Stef: Does this reflect what you think?
@Denis: Is this reasonable for you?

Cheers,
Doru

> On Oct 30, 2016, at 9:33 AM, stepharo <[hidden email]> wrote:
>
> Denis
>
> We are working since 4 years now to get
>
> - have a small kernel + tests
>
> - be able to load nicely configurations
>
> We should not add something else than Sunit for tests of the small kernels tests.
>
> Now people can use whatever they want to test their system but for the core
>
> we are really picky because loading on single package may add far too many dependencies.
>
> and it means
>
> - more time to load
>
> - more time to debug
>
> - more time to just understand what did not work during the bootstrap.
>
> So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them.
>
> I agree with Guillermo. Far too much pain.
>
> Stef
>
> Le 28/10/16 à 18:51, Denis Kudriashov a écrit :
>> We always said that smalltalk is the best for TDD.
>> But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
>> So no kernel tests could benefit from them.
>> And more important TDD is design process and without mocks we can't apply it to kernel with full power.
>> What you think to integrate Mocketry in Pharo 6?
>> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.
>>
>> Best regards,
>> Denis
>
>

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."

Nicolai Hess-3-2

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-30 11:52 GMT+01:00 Nicolai Hess <[hidden email]>:

2016-10-30 11:41 GMT+01:00 Tudor Girba <[hidden email]>:
Hi,

I actually think there is no disagreement in this discussion :).

I am not sure about that.

I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that:
- Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks.
- Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely.

Denis wants to have a Mock-Framework to be used for SUnit, and if we have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to be in it too, no ?

From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features.

Feature freeze? Really, since when?

Does it means any changes (I am working on) for keymapping and style settings has to be moved to Pharo 7?

However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside.

@Guille, Stef: Does this reflect what you think?
@Denis: Is this reasonable for you?

Cheers,
Doru

> On Oct 30, 2016, at 9:33 AM, stepharo <[hidden email]> wrote:
>
> Denis
>
> We are working since 4 years now to get
>
> - have a small kernel + tests
>
> - be able to load nicely configurations
>
> We should not add something else than Sunit for tests of the small kernels tests.
>
> Now people can use whatever they want to test their system but for the core
>
> we are really picky because loading on single package may add far too many dependencies.
>
> and it means
>
> - more time to load
>
> - more time to debug
>
> - more time to just understand what did not work during the bootstrap.
>
> So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them.
>
> I agree with Guillermo. Far too much pain.
>
> Stef
>
> Le 28/10/16 à 18:51, Denis Kudriashov a écrit :
>> We always said that smalltalk is the best for TDD.
>> But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
>> So no kernel tests could benefit from them.
>> And more important TDD is design process and without mocks we can't apply it to kernel with full power.
>> What you think to integrate Mocketry in Pharo 6?
>> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.
>>
>> Best regards,
>> Denis
>
>

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."

Tudor Girba-2

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

Hi,

> On Oct 30, 2016, at 11:55 AM, Nicolai Hess <[hidden email]> wrote:
>
>
>
> 2016-10-30 11:52 GMT+01:00 Nicolai Hess <[hidden email]>:
>
>
> 2016-10-30 11:41 GMT+01:00 Tudor Girba <[hidden email]>:
> Hi,
>
> I actually think there is no disagreement in this discussion :).
>
> I am not sure about that.
>
>
> I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that:
> - Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks.
> - Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely.
>
>
> Denis wants to have a Mock-Framework to be used for SUnit, and if we have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to be in it too, no ?
>
> From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features.
>
> Feature freeze? Really, since when?
>
> Does it means any changes (I am working on) for keymapping and style settings has to be moved to Pharo 7?
>

There was an email sent by Esteban recently in the thread:
Notes about Pharo 6 release and new process for Pharo 7

I think that things like your work on keymapping should still make it in this release.

Cheers,
Doru

> However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside.
>
> @Guille, Stef: Does this reflect what you think?
> @Denis: Is this reasonable for you?
>
> Cheers,
> Doru
>
>
>
> > On Oct 30, 2016, at 9:33 AM, stepharo <[hidden email]> wrote:
> >
> > Denis
> >
> > We are working since 4 years now to get
> >
> > - have a small kernel + tests
> >
> > - be able to load nicely configurations
> >
> > We should not add something else than Sunit for tests of the small kernels tests.
> >
> > Now people can use whatever they want to test their system but for the core
> >
> > we are really picky because loading on single package may add far too many dependencies.
> >
> > and it means
> >
> > - more time to load
> >
> > - more time to debug
> >
> > - more time to just understand what did not work during the bootstrap.
> >
> > So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them.
> >
> > I agree with Guillermo. Far too much pain.
> >
> > Stef
> >
> > Le 28/10/16 à 18:51, Denis Kudriashov a écrit :
> >> We always said that smalltalk is the best for TDD.
> >> But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
> >> So no kernel tests could benefit from them.
> >> And more important TDD is design process and without mocks we can't apply it to kernel with full power.
> >> What you think to integrate Mocketry in Pharo 6?
> >> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.
> >>
> >> Best regards,
> >> Denis
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Value is always contextual."

--
www.tudorgirba.com
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

Nicolai Hess-3-2

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

2016-10-30 12:00 GMT+01:00 Tudor Girba <[hidden email]>:

Hi,

> On Oct 30, 2016, at 11:55 AM, Nicolai Hess <[hidden email]> wrote:
>
>
>
> 2016-10-30 11:52 GMT+01:00 Nicolai Hess <[hidden email]>:
>
>
> 2016-10-30 11:41 GMT+01:00 Tudor Girba <[hidden email]>:
> Hi,
>
> I actually think there is no disagreement in this discussion :).
>
> I am not sure about that.
>
>
> I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that:
> - Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks.
> - Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely.
>
>
> Denis wants to have a Mock-Framework to be used for SUnit, and if we have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to be in it too, no ?
>
> From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features.
>
> Feature freeze? Really, since when?
>
> Does it means any changes (I am working on) for keymapping and style settings has to be moved to Pharo 7?
>

There was an email sent by Esteban recently in the thread:
Notes about Pharo 6 release and new process for Pharo 7

Oh, I thought it was only about a "VM feature freeze", for having a stable version to work towards 64 bits VM.

That is unfortunate, I have some other things I am working on and thought I would have time until february, as in the prior relaese cycles.

I think that things like your work on keymapping should still make it in this release.

Cheers,
Doru

> However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside.
>
> @Guille, Stef: Does this reflect what you think?
> @Denis: Is this reasonable for you?
>
> Cheers,
> Doru
>
>
>
> > On Oct 30, 2016, at 9:33 AM, stepharo <[hidden email]> wrote:
> >
> > Denis
> >
> > We are working since 4 years now to get
> >
> > - have a small kernel + tests
> >
> > - be able to load nicely configurations
> >
> > We should not add something else than Sunit for tests of the small kernels tests.
> >
> > Now people can use whatever they want to test their system but for the core
> >
> > we are really picky because loading on single package may add far too many dependencies.
> >
> > and it means
> >
> > - more time to load
> >
> > - more time to debug
> >
> > - more time to just understand what did not work during the bootstrap.
> >
> > So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them.
> >
> > I agree with Guillermo. Far too much pain.
> >
> > Stef
> >
> > Le 28/10/16 à 18:51, Denis Kudriashov a écrit :
> >> We always said that smalltalk is the best for TDD.
> >> But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
> >> So no kernel tests could benefit from them.
> >> And more important TDD is design process and without mocks we can't apply it to kernel with full power.
> >> What you think to integrate Mocketry in Pharo 6?
> >> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.
> >>
> >> Best regards,
> >> Denis
> >
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Value is always contextual."

--
www.tudorgirba.com
www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

NorbertHartl

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Tudor Girba-2

The context might be right. Still Denis is talking about integrating Mocks in SUnit. And to have kernel tests using Mocks. I don't see a problem because can be loaded later. I see no reason if there is a small kernel why it cannot load additional stuff just for testing. The kernel would still be small. If things packaged the right way tests can be loaded in multiple feature layers.
The not yet to discuss thing is indeed what will be the default distribution of pharo.

Norbert

> Am 30.10.2016 um 11:41 schrieb Tudor Girba <[hidden email]>:
>
> Hi,
>
> I actually think there is no disagreement in this discussion :). I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that:
> - Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks.
> - Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely.
>
> From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features. However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside.
>
> @Guille, Stef: Does this reflect what you think?
> @Denis: Is this reasonable for you?
>
> Cheers,
> Doru
>
>
>
>> On Oct 30, 2016, at 9:33 AM, stepharo <[hidden email]> wrote:
>>
>> Denis
>>
>> We are working since 4 years now to get
>>
>> - have a small kernel + tests
>>
>> - be able to load nicely configurations
>>
>> We should not add something else than Sunit for tests of the small kernels tests.
>>
>> Now people can use whatever they want to test their system but for the core
>>
>> we are really picky because loading on single package may add far too many dependencies.
>>
>> and it means
>>
>> - more time to load
>>
>> - more time to debug
>>
>> - more time to just understand what did not work during the bootstrap.
>>
>> So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them.
>>
>> I agree with Guillermo. Far too much pain.
>>
>> Stef
>>
>>> Le 28/10/16 à 18:51, Denis Kudriashov a écrit :
>>> We always said that smalltalk is the best for TDD.
>>> But we not have mocks by default in Pharo while mocks is fundamental part of TDD.
>>> So no kernel tests could benefit from them.
>>> And more important TDD is design process and without mocks we can't apply it to kernel with full power.
>>> What you think to integrate Mocketry in Pharo 6?
>>> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries.
>>>
>>> Best regards,
>>> Denis
>>
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Value is always contextual."
>
>
>
>
>

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Tudor Girba-2

2016-10-30 11:41 GMT+01:00 Tudor Girba <[hidden email]>:

@Denis: Is this reasonable for you?

It is better than nothing :).

Sean P. DeNigris

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

Administrator

In reply to this post by NorbertHartl

NorbertHartl wrote

I see no reason if there is a small kernel why it cannot load additional stuff just for testing.

+1. Why would /any/ test framework (including SUnit) be included in the kernel?! And a big +1 to adding mocks to the default test framework, in whatever layer that gets loaded. Philosophical discussions about mocks aside, the programming world (full disclosure: including myself) has embraced them, and their absence seems unnecessarily restrictive and isolationist. While the bits of a BDD behavioral specification might not be any different from the average unit test, I've found the mindset they create is invaluable to keeping the focus on "what should this object do" instead of "does it work" (which comes along for free). I'd say we could use any possible help toward that paradigm shift. Some (many? most?) of our kernel tests seem brittle, duplicative, and, worst of all, of little use as documentation.

p.s. although I don't have a ton of experience with Mocketry, when I shopped around for a mock framework, I remember strongly preferring BabyMock (which I hacked together with Phexample into BabyPhexample; so you get stacked tests, "should" expectations, and mocks). Maybe in another thread, Denis might explain why one might prefer Mocketry?

Cheers,
Sean

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

Hi Sean.

2016-10-31 14:23 GMT+01:00 Sean P. DeNigris <[hidden email]>:

p.s. although I don't have a ton of experience with Mocketry, when I shopped
around for a mock framework, I remember strongly preferring BabyMock (which
I hacked together with Phexample into BabyPhexample; so you get stacked
tests, "should" expectations, and mocks). Maybe in another thread, Denis
might explain why one might prefer Mocketry?

You can look at features here: http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.

BabyMock could not be treated as modern mock library just because it uses symbols instead of normal message sends. Even C# and Java mocks are based on normal messages.

But BabyMock implements really nice visualization of objects interaction which probably was main goal for authors.

It could be done for Mocketry but with ready to use tools like Roassal. BabyMock implements all visualization by itself.

Denis Kudriashov

Re: Mocks are missing in Pharo (from thread OSProcess is missing)

In reply to this post by Sean P. DeNigris

2016-10-31 14:23 GMT+01:00 Sean P. DeNigris <[hidden email]>:

While the bits of a BDD behavioral specification might not be
any different from the average unit test, I've found the mindset they create
is invaluable to keeping the focus on "what should this object do" instead
of "does it work" (which comes along for free).

I would love to have something more then tests as methods. If tests are documentation then we are managing documentation with only two level of chapters: classes and methods. Not really nice book.