[Pharo-project] Dev images with or without tests?
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate: (ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image) or (ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests' which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests). So, my question is, should the test be included in the default dev image? I think that yes, because of the following: 1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction So..what do you think ? Cheers Mariano
I vote for their presence for all the reasons you mentioned. Cheers, Doru On 5 Jan 2010, at 22:11, Mariano Martinez Peck wrote:
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate:
(ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image)
or
(ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests'
which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests).
So, my question is, should the test be included in the default dev image?
I think that yes, because of the following:
1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction
So..what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Beauty is where we see it."
+1 especially if we have a script to take a rc and produce a dev without test if necessary
I vote for their presence for all the reasons you mentioned.
Cheers, Doru
On 5 Jan 2010, at 22:11, Mariano Martinez Peck wrote:
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate:
(ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image)
or
(ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests'
which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests).
So, my question is, should the test be included in the default dev image?
I think that yes, because of the following:
1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction
So..what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Beauty is where we see it."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1 Alexandre On 5 Jan 2010, at 18:15, Tudor Girba wrote:
I vote for their presence for all the reasons you mentioned.
Cheers, Doru
On 5 Jan 2010, at 22:11, Mariano Martinez Peck wrote:
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate:
(ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image)
or
(ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests'
which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests).
So, my question is, should the test be included in the default dev image?
I think that yes, because of the following:
1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction
So..what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Beauty is where we see it."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Mariano Martinez Peck wrote:
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer).
You need to build and provide both types of images. The developer then decides which one they need based on whether or not they expect to be modifying "base" code. For example, if I'm just writing a Seaside app. that does not change Seaside itself, I would not want the Seaside tests around. It may be wise to have my build server load and run them, and let me know of test failures - but, the day to day development image should not have them. If however, when building my app., I found I was modifying and extending Seaside itself, then I would choose to use a base image that included the Seaside tests. In order to keep a build time under 10 minutes, as things scale, you need to build and test the pieces individually. Then you start your development from a known and tested baseline image. BTW, the Hudson build stuff I just announced, has this build/test scenario in mind. The "product" itself is built and saved. Then the test packages are added, and the test cases are run. Unfortunately, when the test cases are in the same package, they cannot be left out of the "product" image. In the Pier build example, some addon packages which included tests are loaded in the test build. It's not right, because the product image is missing these addon packages. There's a test package dependency chain, that could not be solved, because the tests and code were in the same package. -- Yanni Chiu
For example, if I'm just writing a Seaside app. that does not change Seaside itself, I would not want the Seaside tests around.
I have a different opinion Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel wrote:
For example, if I'm just writing a Seaside app. that does not change Seaside itself, I would not want the Seaside tests around.
I have a different opinion
Okay, Seaside was just one example package I chose for illustration. Perhaps it was not the best choice, since I said I was building a Seaside application. What about Collections tests or Morphic tests? Also, not having them around, doesn't mean never running them. They could be run by a build process, and I would be told if they failed. Meanwhile, I would never be distracted by their presence. I would not have to think about which SUnit tests to run; I would just run all the ones in my image. -- Yanni
It is more for having examples under hands. Cheers, Alexandre On 6 Jan 2010, at 13:29, Yanni Chiu wrote:
Alexandre Bergel wrote:
For example, if I'm just writing a Seaside app. that does not change Seaside itself, I would not want the Seaside tests around.
I have a different opinion
Okay, Seaside was just one example package I chose for illustration. Perhaps it was not the best choice, since I said I was building a Seaside application. What about Collections tests or Morphic tests?
Also, not having them around, doesn't mean never running them. They could be run by a build process, and I would be told if they failed. Meanwhile, I would never be distracted by their presence. I would not have to think about which SUnit tests to run; I would just run all the ones in my image.
-- Yanni
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre, Once upon a time I thought like you, but I changed my mind when I realized that more and more the tests are being engineered in such a fashion that using them for the sake of an example is becoming convoluted. As we create all the machinery (setup and tear down) to do Unit Tests the test itself conveys less information unless you start to navigate the SUnit land, and I feel it will become even more inexpugnable for newcomers as soon PhExample enters the scene (you might have chained tests). Notwithstanding the accepted notion that tests are a form of documentation, I would say more and more they're falling into the same slot of the argument "you have access to the code": true but not practical for the day to day chores. -- Cesar Rabak Em 06/01/2010 14:58, Alexandre Bergel < alexandre@bergel.eu > escreveu: It is more for having examples under hands. Cheers, Alexandre
El mié, 06-01-2010 a las 16:56 -0200, csrabak@bol.com.br escribió:
Alexandre,
Once upon a time I thought like you, but I changed my mind when I realized that more and more the tests are being engineered in such a fashion that using them for the sake of an example is becoming convoluted.
As we create all the machinery (setup and tear down) to do Unit Tests the test itself conveys less information unless you start to navigate the SUnit land, and I feel it will become even more inexpugnable for newcomers as soon PhExample enters the scene (you might have chained tests).
Notwithstanding the accepted notion that tests are a form of documentation, I would say more and more they're falling into the same slot of the argument "you have access to the code": true but not practical for the day to day chores.
+1 I agree with you 100% but I vote for maintaining the tests in the dev image and giving the users a quick/easy/transcript ready way to unload them if they want. Also, for deploy scenarios, the intended way is to use a PharoCore image and use a personalized script (with gofer/metacello) to load only the packages needed. -- Miguel Cobá http://miguel.leugim.com.mx
2010/1/6 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
El mié, 06-01-2010 a las 16:56 -0200, csrabak@bol.com.br escribió:
Alexandre,
Once upon a time I thought like you, but I changed my mind when I realized that more and more the tests are being engineered in such a fashion that using them for the sake of an example is becoming convoluted.
As we create all the machinery (setup and tear down) to do Unit Tests the test itself conveys less information unless you start to navigate the SUnit land, and I feel it will become even more inexpugnable for newcomers as soon PhExample enters the scene (you might have chained tests).
Notwithstanding the accepted notion that tests are a form of documentation, I would say more and more they're falling into the same slot of the argument "you have access to the code": true but not practical for the day to day chores.
+1
I agree with you 100% but I vote for maintaining the tests in the dev image and giving the users a quick/easy/transcript ready way to unload them if they want.
Yes. Would be cool if some one can see what I said about ScriptLoader cleanUpForProduction.
Also, for deploy scenarios, the intended way is to use a PharoCore image and use a personalized script (with gofer/metacello) to load only the packages needed.
BUt even the core have tests. So, even if you load your packages by hand, you may want to unload the tests of the core. Maybe you don't. It is up to you :)
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1 for an image with tests. Fréd ---- Frédéric Pluquet Université Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/1/5 Mariano Martinez Peck <marianopeck@gmail.com>
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate:
(ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image)
or
(ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests'
which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests).
So, my question is, should the test be included in the default dev image?
I think that yes, because of the following:
1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction
So..what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Decision taken then :) I will then explain how to load an image without tests for those rebelds people ;) cheers 2010/1/6 Frederic Pluquet <fpluquet@ulb.ac.be>
+1 for an image with tests.
Fréd ---- Frédéric Pluquet Université Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet
2010/1/5 Mariano Martinez Peck <marianopeck@gmail.com>
Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate:
(ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image)
or
(ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests'
which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests).
So, my question is, should the test be included in the default dev image?
I think that yes, because of the following:
1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction
So..what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Alexandre Bergel -
csrabak＠bol.com.br -
Frederic Pluquet -
Mariano Martinez Peck -
Miguel Enrique Cobá Martinez -
Stéphane Ducasse -
Tudor Girba -
Yanni Chiu