Pyret: adding tests directly into classes
I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes. I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests. Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X? Cheers Andy
I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests. The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample). Cheers, Doru On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett < andy.burnett@knowinnovation.com> wrote:
I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes.
I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests.
Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X?
Cheers Andy
-- www.tudorgirba.com "Every thing has its own flow"
On 17 nov. 2013, at 15:16, Tudor Girba <tudor@tudorgirba.com> wrote:
I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests.
The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample).
Cheers, Doru
There was a presentation of the Pyret language at SCRIPT workshop last week. This way of coupling unit tests with functions is indeed interesting. One the one hand I feel it's like a mixing of concerns, on the other hand it's push unit-tests into the language. The funny part is that the examples provided are used to type the function: fun id(x): x where: id(3) is 3 id("bla") is "bla" end is typed as 'a -> 'a whereas: fun id(x): x where: id(3) is 3 end is typed as int -> int
On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett <andy.burnett@knowinnovation.com> wrote: I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes.
I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests.
Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X?
Cheers Andy
-- www.tudorgirba.com
"Every thing has its own flow"
I don't like having the Unit Tests so coupled with the code. Many times I implement Unit Tests that doesn't match 1:1 with a class. It is... the TestCase subclass doesn't have a corresponding class (eg. SomeFeatureTest, with no SomeFeature class in the system). Regards, Esteban A. Maringolo 2013/11/18 Camille Teruel <camille.teruel@gmail.com>:
On 17 nov. 2013, at 15:16, Tudor Girba <tudor@tudorgirba.com> wrote:
I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests.
The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample).
Cheers, Doru
There was a presentation of the Pyret language at SCRIPT workshop last week. This way of coupling unit tests with functions is indeed interesting. One the one hand I feel it's like a mixing of concerns, on the other hand it's push unit-tests into the language. The funny part is that the examples provided are used to type the function:
fun id(x): x where: id(3) is 3 id("bla") is "bla" end
is typed as 'a -> 'a whereas:
fun id(x): x where: id(3) is 3 end
is typed as int -> int
On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes.
I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests.
Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X?
Cheers Andy
-- www.tudorgirba.com
"Every thing has its own flow"
On 18 nov. 2013, at 13:07, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I don't like having the Unit Tests so coupled with the code.
Many times I implement Unit Tests that doesn't match 1:1 with a class. It is... the TestCase subclass doesn't have a corresponding class (eg. SomeFeatureTest, with no SomeFeature class in the system).
IMO, you're talking about functional tests, not unit tests. While a unit test is done in isolation and is concerned with one "unit" (typically a method), an acceptance test tests a feature of your application that will typically crosscut many units. In Pyret, they have another clause "check" for that purpose.
Regards,
Esteban A. Maringolo
2013/11/18 Camille Teruel <camille.teruel@gmail.com>:
On 17 nov. 2013, at 15:16, Tudor Girba <tudor@tudorgirba.com> wrote:
I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests.
The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample).
Cheers, Doru
There was a presentation of the Pyret language at SCRIPT workshop last week. This way of coupling unit tests with functions is indeed interesting. One the one hand I feel it's like a mixing of concerns, on the other hand it's push unit-tests into the language. The funny part is that the examples provided are used to type the function:
fun id(x): x where: id(3) is 3 id("bla") is "bla" end
is typed as 'a -> 'a whereas:
fun id(x): x where: id(3) is 3 end
is typed as int -> int
On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes.
I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests.
Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X?
Cheers Andy
-- www.tudorgirba.com
"Every thing has its own flow"
Esteban, good point. I use Tests sometimes as a mixture of design help and living documentation. And there, test cases almost never match classes 1:1. And I also think that is a good thing. Especially when it comes to refactoring and major redesign where the API of some entry points to a certain functional unit must not be changed. One could now start a new discussion on whether this use case is "unit testing" or now, but I guess we can be glad when people write any kind of test ;-) Not every thing that should be improved can be improved by changing tools. Sometimes it really is a people thing. Joachim Am 18.11.13 13:07, schrieb Esteban A. Maringolo:
I don't like having the Unit Tests so coupled with the code.
Many times I implement Unit Tests that doesn't match 1:1 with a class. It is... the TestCase subclass doesn't have a corresponding class (eg. SomeFeatureTest, with no SomeFeature class in the system).
Regards,
Esteban A. Maringolo
2013/11/18 Camille Teruel <camille.teruel@gmail.com>:
On 17 nov. 2013, at 15:16, Tudor Girba <tudor@tudorgirba.com> wrote:
I stumbled across this idea when Markus Gaelli chose it as a PhD topic about ten years ago (man, I'm old). The main idea was not to provide tests, but examples that happened to have assertions. The goal was twofold: (1) provide live documentation with real objects, (2) provide another way of composing tests.
The project did not really come to fruition, but I still think this is highly interesting topic. Part of the ideas were later implemented in Phexample (http://www.smalltalkhub.com/#!/~Phexample/Phexample/) and JExample (http://scg.unibe.ch/research/jexample).
Cheers, Doru
There was a presentation of the Pyret language at SCRIPT workshop last week. This way of coupling unit tests with functions is indeed interesting. One the one hand I feel it's like a mixing of concerns, on the other hand it's push unit-tests into the language. The funny part is that the examples provided are used to type the function:
fun id(x): x where: id(3) is 3 id("bla") is "bla" end
is typed as 'a -> 'a whereas:
fun id(x): x where: id(3) is 3 end
is typed as int -> int
On Sun, Nov 17, 2013 at 3:08 PM, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes.
I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests.
Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X?
Cheers Andy
-- www.tudorgirba.com
"Every thing has its own flow"
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Hi, It does not really matters where you put the test. What matters is to have the tools that show them properly, and we are going in that direction. We already have ways to "jump to tests" in Nautilus, and we will continue improving that to show them together (for example). But I do not think the tests need to be *in* the class definition to have same level of interoperation. Esteban On Nov 17, 2013, at 3:08 PM, Andy Burnett <andy.burnett@knowinnovation.com> wrote:
I have just come across the Pyret language. It looks interesting, but the part which particularly caught my interest was the way that they had built the unit tests directly into the classes, rather than having separate test classes.
I think this is an interesting idea. It seems as though it would be easier to manage writing tests if everything were in one location. And this - might - mean that people were more likely to write tests.
Has anyone else looked at this, and have an opinion on whether it would be a good addition to Pharo 4/5/X?
Cheers Andy
participants (7)
-
Andy Burnett -
Camille Teruel -
Esteban A. Maringolo -
Esteban Lorenzano -
jtuchel＠objektfabrik.de -
Stéphane Ducasse -
Tudor Girba