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
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" <dionisiydk@gmail.com> 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
2016-10-28 18:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
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.
On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-10-28 18:58 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
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**
2016-10-28 16:07 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <dionisiydk@gmail.com> 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.
2016-10-28 21:07 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
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
2016-10-28 21:07 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
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.
2016-10-29 0:12 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
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?
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 <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>>:
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 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
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 <stepharo@free.fr> 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."
2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
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 <stepharo@free.fr> 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."
2016-10-30 11:52 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
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 <stepharo@free.fr> 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."
Hi,
On Oct 30, 2016, at 11:55 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-10-30 11:52 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: 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 <stepharo@free.fr> 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."
2016-10-30 12:00 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Oct 30, 2016, at 11:55 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-10-30 11:52 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:
2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: 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 <stepharo@free.fr> 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."
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 <tudor@tudorgirba.com>:
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 <stepharo@free.fr> 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."
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 -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Sean. 2016-10-31 14:23 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
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 wrote
You can look at features here: http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.
Ah, yes. I seem to recall one major hurdle for me was that each test needed everything wrapped in a block. Is that still the case? Could this be hidden somewhere in the mechanism? I also wonder whether Mocketry could be easily integrated with Phexample, as I really love the stacked test concept... Denis Kudriashov wrote
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.
In practice, I don't see why this makes such a big difference. What am I missing? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I completely agree, I am all for minimal image and then the user should be able to install anything he/she wants through Catalog Browser, I think we need to make sure that the welcome text clearly illustrate this and that the new user is not confused. But that means that you the people who create project that are not in the main distribution make sure your project is on Catalog Browser and that there is a clear description of what it does. Pharo already an excellent mechanism for installing packages. Just today I tried to install OSC library in Pharo 5 though monticello and configuration and I failed, then I tried the Catalog Browser and worked like a charm. Big thanks to Esteban for this amazing tool is by far my favorite, second being GTSpotter of course ;) On Mon, Oct 31, 2016 at 5:50 PM Sean P. DeNigris <sean@clipperadams.com> wrote:
Denis Kudriashov wrote
You can look at features here: http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.
Ah, yes. I seem to recall one major hurdle for me was that each test needed everything wrapped in a block. Is that still the case? Could this be hidden somewhere in the mechanism? I also wonder whether Mocketry could be easily integrated with Phexample, as I really love the stacked test concept...
Denis Kudriashov wrote
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.
In practice, I don't see why this makes such a big difference. What am I missing?
----- Cheers, Sean -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-10-31 16:40 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
You can look at features here: http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html.
Ah, yes. I seem to recall one major hurdle for me was that each test needed everything wrapped in a block. Is that still the case? Could this be hidden somewhere in the mechanism?
It was changed in version 3. Now blocks could be used to easily get multiple mocks (as block arguments) or to validate group of messages. But it is not necessary. You can just work with separate mocks created by "Mock new". So you don't need blocks generally. I thought it was seen in my blog post.
I also wonder whether Mocketry could be easily integrated with Phexample, as I really love the stacked test concept...
Months ago I committed version of Phexample based on StateSpecs (new config in Phexample repo). So all projects are compatible.
Denis Kudriashov wrote
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.
In practice, I don't see why this makes such a big difference. What am I missing?
For me it is just not readable, more code to write. But also it makes tests fragile for refactorings. Try to change signature of method: new argument, remove argument, switch argument places. And tests will be broken (because mocks use symbols and not real messages).
Denis Kudriashov wrote
So you don't need blocks generally. I thought it was seen in my blog post.
I guess I was confused by "Also there is way to get multiple mocks at once: [ :mockA :mockB | "your code here" ] runWithMocks" Denis Kudriashov wrote
all projects are compatible.
Great! Denis Kudriashov wrote
But also it makes tests fragile for refactorings
Ah, very good point! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Denis Kudriashov wrote
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.
Because they don't have symbols :). Ruby libraries often use symbols, last time I checked rspec mocks used it too. I think this is a matter of taste, it's not about being modern or not. I like thinking about mock objects as tools for describing inter-object protocols (the visualisation tries to emphasize this aspect). The communication protocol between the object under test and its peers (mocks) is expressed in a descriptive language (this language can be changed in BabyMock quite easily). A narrator object (this is called Protocol in BabyMock2) speaks in the third person to describe the message exchange between the object cluster. I don't like when expectations are set up in mocks directly any more, neither the should/should have notation. The GOOS book was a big influence on me at that time. -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-11-01 11:50 GMT+01:00 Attila Magyar <m.magyar3@gmail.com>:
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.
Because they don't have symbols :).
They have strings. And first mock libraries used message names as strings. And any method rename broke tests.
Ruby libraries often use symbols, last time I checked rspec mocks used it too. I think this is a matter of taste, it's not about being modern or not.
Probably it looks not so bad with C-like syntax because everything is just function name and arguments inside parenthesise. But with Smalltalk keywords syntax it looks horrible. I not believe that anybody would prefer writing: protocol describe once: socket recv: #connectTo:port:waitForConnectionFor: with: address with: port with: timeout. over simple: socket stub connectTo: address port: port waitForConnectionFor: timeout. And as I said symbol(string) based version is not safe for refactorings.
I like thinking about mock objects as tools for describing inter-object protocols (the visualisation tries to emphasize this aspect).
I agree with you.
The communication protocol between the object
under test and its peers (mocks)
is expressed in a descriptive language (this language can be changed in BabyMock quite easily). A narrator object (this is called Protocol in BabyMock2) speaks in the third person to describe the message exchange between the object cluster. I don't like when expectations are set up in mocks directly any more,
It leads to more code which you will write again and again in your tests. And this code is nothing about actual business which tests describe. In Mocketry there is also a guy who manages all specifications and collects all interactions but it's hidden from user. With Mocketry I try to make mocks as simple as possible without losing power.
neither the should/should have notation. The GOOS book was a big influence on me at that time.
They have strings. And first mock libraries used message names as strings
They are not the same. Method rename and find senders works with symbols but not with strings. Some rarely used refactorings might not work, although this is probably a technical limitation of the refactoring engine and not a conceptual one.
not believe that anybody would prefer writing
In Ruby this would look like something like this. allow(socket).to receive(:connect).with(address, port, timeout) { do_something } Not so different and many people use this. Probably lot more than the users of Mocketry + BabyMock together. (Anyways probably I wouldn't use a mock library to stub an object like a socket. It is not my own type, too low-level abstraction. It results brittle tests no matter what syntax is used.)
It leads to more code which you will write again and again in your tests
If I have too many code for setting up expectations and mocks that is a clear clue that something went wrong in my test, and I rather have a mock library that makes this painful early on. It is really easy to make a mess with mock object based tests. This is why I still prefer jMock over any other mock object library (mockito, easymock) in Java. JMock is a highly opinionated library that deliberately doesn't support features like deep stubbing, partial mocking and other black magic stuffs. BabyMock follows a similar philosophy. -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-11-01 18:27 GMT+01:00 Attila Magyar <m.magyar3@gmail.com>:
They have strings. And first mock libraries used message names as strings
They are not the same. Method rename and find senders works with symbols but not with strings. Some rarely used refactorings might not work, although this is probably a technical limitation of the refactoring engine and not a conceptual one.
No matter. This is what we have. And with message based approach this problem not exists at all. 2016-11-01 18:27 GMT+01:00 Attila Magyar <m.magyar3@gmail.com>:
not believe that anybody would prefer writing
In Ruby this would look like something like this.
allow(socket).to receive(:connect).with(address, port, timeout) { do_something }
This is exactly what I said: with C-like syntax it is normal but not with keyword messages.
Not so different and many people use this. Probably lot more than the users of Mocketry + BabyMock together.
(Anyways probably I wouldn't use a mock library to stub an object like a socket. It is not my own type, too low-level abstraction. It results brittle tests no matter what syntax is used.)
It was just example where everybody could see agliness of string based approach.
It leads to more code which you will write again and again in your tests
If I have too many code for setting up expectations and mocks that is a clear clue that something went wrong in my test,
I use mocks in most unit tests. So in every test I will need to repeat all this code.
and I rather have a mock library that makes this painful early on. It is really easy to make a mess with mock object based tests. This is why I still prefer jMock over any other mock object library (mockito, easymock) in Java. JMock is a highly opinionated library that deliberately doesn't support features like deep stubbing, partial mocking and other black magic stuffs. BabyMock follows a similar philosophy.
Smalltalk is super powerful language which allows easily create and run tons of spaghetti code. But with C++ it is sometime impossible to just compile spaghetti code. So C++ prevents programmers from writing bad code because without discipline you can't run your program. So if you want to be good programmer choose C++. (sorry for sarcasm)
And with message based approach this problem not exists at all.
Yes, it has different tradeoffs. For example you have to fill in the parameters even if you want to ignore them, or it is difficult (maybe impossibe) to express a parameter matcher that considers the relationship of multiple arguments (for example /allow: mock recv: #a:b:; with: [:a :b | a > b]/). But I dont want to go off topic. I just disagree that this arbitrary and subjective feature makes something "modern" or not. Anyways, good luck with Mocketry. -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-mi... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-11-01 20:45 GMT+01:00 Attila Magyar <m.magyar3@gmail.com>:
Yes, it has different tradeoffs. For example you have to fill in the parameters even if you want to ignore them, or it is difficult (maybe impossibe) to express a parameter matcher that considers the relationship of multiple arguments (for example /allow: mock recv: #a:b:; with: [:a :b | a
b]/).
If you don't care about parameters you can use Any: socket stub connectTo: Any port: Any waitForConnectionFor: Any. Last case is a bit tricky of course but possible: mock stub a: [:arg1 | a := arg1. true] b: [:b | a > b] And it is easy to extend Mocketry for string based scenario: mock stub message: #a:b: with: [:a :b | a > b]. But I don't see value for this.
2016-10-31 14:23 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
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.
participants (11)
-
Attila Magyar -
Dale Henrichs -
Denis Kudriashov -
Dimitris Chloupis -
Esteban A. Maringolo -
Guillermo Polito -
Nicolai Hess -
Norbert Hartl -
Sean P. DeNigris -
stepharo -
Tudor Girba