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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Beauty is where we see it." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
+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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Tudor Girba
+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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
+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 <[hidden email]> 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: _______________________________________________ Pharo-project mailing list [hidden email] 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 <[hidden email]> +1 for an image with tests. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Alexandre Bergel
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 < [hidden email] > escreveu: It is more for having examples under hands. Cheers, Alexandre _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
El mié, 06-01-2010 a las 16:56 -0200, [hidden email] 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/1/6 Miguel Enrique Cobá Martinez <[hidden email]> El mié, 06-01-2010 a las 16:56 -0200, [hidden email] escribió: Yes. Would be cool if some one can see what I said about ScriptLoader cleanUpForProduction.
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 :) -- _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |