- Pharo-dev - lists.pharo.org

Re: [Pharo-project] setUp and test methods

by Alexandre Bergel

Indeed, refactorings for unit tests are completely absent from the software engineering community. Alexandre On 19 Aug 2011, at 15:39, laurent laffont wrote: > > > On Fri, Aug 19, 2011 at 3:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Before leading a revolution, we can maybe have this work for unit test first :-) > > Actually, when I think about it, having not the setUp visible when writing tests make the setUp functionality mostly useless. > > > Also, I usually write the setUp to remove duplication, so often after the second test method. A refactoring "extract to setUp" would be cool too. > > Another point, when I have a hierarchy of TestCase I often feel I need a "merged setUp view" > > Laurent. > > > > Cheers, > Alexandre > > > On 19 Aug 2011, at 15:19, laurent laffont wrote: > > > On Fri, Aug 19, 2011 at 3:09 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > > > I know there are many TDD shoguns around. > > > > I was wondering whether I am the only one suffering from the need to see the definition of setUp before writing a test method. Unfortunately, current tool does not automatically show the definition of setUp when I want to write a new test. > > The cost of seeing how the setUp is done is high: need to open a new window, clicking to restore the context on the first window, ... > > > > Am I the only one? > > > > > > No. I would like too. > > > > But not only for tests. I often need to look at several related methods at once while developing. > > > > Laurent. > > > > > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2011

Re: [Pharo-project] setUp and test methods

by laurent laffont

On Fri, Aug 19, 2011 at 3:23 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Before leading a revolution, we can maybe have this work for unit test > first :-) > > Actually, when I think about it, having not the setUp visible when writing > tests make the setUp functionality mostly useless. > Also, I usually write the setUp to remove duplication, so often after the second test method. A refactoring "extract to setUp" would be cool too. Another point, when I have a hierarchy of TestCase I often feel I need a "merged setUp view" Laurent. > > Cheers, > Alexandre > > > On 19 Aug 2011, at 15:19, laurent laffont wrote: > > > On Fri, Aug 19, 2011 at 3:09 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > Hi! > > > > I know there are many TDD shoguns around. > > > > I was wondering whether I am the only one suffering from the need to see > the definition of setUp before writing a test method. Unfortunately, current > tool does not automatically show the definition of setUp when I want to > write a new test. > > The cost of seeing how the setUp is done is high: need to open a new > window, clicking to restore the context on the first window, ... > > > > Am I the only one? > > > > > > No. I would like too. > > > > But not only for tests. I often need to look at several related methods > at once while developing. > > > > Laurent. > > > > > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

Aug. 19, 2011

Re: [Pharo-project] setUp and test methods

by Alexandre Bergel

Before leading a revolution, we can maybe have this work for unit test first :-) Actually, when I think about it, having not the setUp visible when writing tests make the setUp functionality mostly useless. Cheers, Alexandre On 19 Aug 2011, at 15:19, laurent laffont wrote: > On Fri, Aug 19, 2011 at 3:09 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I know there are many TDD shoguns around. > > I was wondering whether I am the only one suffering from the need to see the definition of setUp before writing a test method. Unfortunately, current tool does not automatically show the definition of setUp when I want to write a new test. > The cost of seeing how the setUp is done is high: need to open a new window, clicking to restore the context on the first window, ... > > Am I the only one? > > > No. I would like too. > > But not only for tests. I often need to look at several related methods at once while developing. > > Laurent. > > > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2011

Re: [Pharo-project] setUp and test methods

by laurent laffont

On Fri, Aug 19, 2011 at 3:09 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi! > > I know there are many TDD shoguns around. > > I was wondering whether I am the only one suffering from the need to see > the definition of setUp before writing a test method. Unfortunately, current > tool does not automatically show the definition of setUp when I want to > write a new test. > The cost of seeing how the setUp is done is high: need to open a new > window, clicking to restore the context on the first window, ... > > Am I the only one? > No. I would like too. But not only for tests. I often need to look at several related methods at once while developing. Laurent. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

Aug. 19, 2011

Re: [Pharo-project] setUp and test methods

by Alexandre Bergel

Having the setUp next to the definition of a test is in my opinion the way to go (subliminal message for Ben :-) Alexandre On 19 Aug 2011, at 15:14, Frank Shearar wrote: > On 19 August 2011 14:09, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> I know there are many TDD shoguns around. >> >> I was wondering whether I am the only one suffering from the need to see the definition of setUp before writing a test method. Unfortunately, current tool does not automatically show the definition of setUp when I want to write a new test. >> The cost of seeing how the setUp is done is high: need to open a new window, clicking to restore the context on the first window, ... >> >> Am I the only one? > > Nope, I suffer from this problem too. I've been thinking about a more > general problem, that of displaying multiple method definitions in the > same place/window/whatever. > > It seems the solution is two-fold: > * write a widget that can display multiple methods in the same pane, and > * tell the system that you want to see certain methods together. > > In the case of tests, you could always use reflection - you're viewing > a method starting with "test" in a TestCase subclass, so if there's a > setUp method (or series of setUp methods, in the case of overriden > methods), display them together. > > frank > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2011

Re: [Pharo-project] setUp and test methods

by Frank Shearar

On 19 August 2011 14:09, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I know there are many TDD shoguns around. > > I was wondering whether I am the only one suffering from the need to see the definition of setUp before writing a test method. Unfortunately, current tool does not automatically show the definition of setUp when I want to write a new test. > The cost of seeing how the setUp is done is high: need to open a new window, clicking to restore the context on the first window, ... > > Am I the only one? Nope, I suffer from this problem too. I've been thinking about a more general problem, that of displaying multiple method definitions in the same place/window/whatever. It seems the solution is two-fold: * write a widget that can display multiple methods in the same pane, and * tell the system that you want to see certain methods together. In the case of tests, you could always use reflection - you're viewing a method starting with "test" in a TestCase subclass, so if there's a setUp method (or series of setUp methods, in the case of overriden methods), display them together. frank

Aug. 19, 2011

[Pharo-project] setUp and test methods

by Alexandre Bergel

Hi! I know there are many TDD shoguns around. I was wondering whether I am the only one suffering from the need to see the definition of setUp before writing a test method. Unfortunately, current tool does not automatically show the definition of setUp when I want to write a new test. The cost of seeing how the setUp is done is high: need to open a new window, clicking to restore the context on the first window, ... Am I the only one? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 19, 2011

Re: [Pharo-project] Smalltalk tools transcript

by Igor Stasenko

On 19 August 2011 14:13, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > On Fri, Aug 19, 2011 at 1:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 19 August 2011 11:41, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> Igor changed some uses of "Transcript" to "Smalltalk tools >>> transcript". Of course it is not bad idea however it has some >>> unwelcome consequences - mainly it cannot work on images that have no >>> tools and Pharo Kernel and most of derived images have no ToolRegistry >>> at all. Currently it breaks Pharo Kernel job on CI server. >>> >>> Here are affected methods: >>> >>> Object>>crLog: {logging} >>> Object>>log: {logging} >>> Object>>logCr: {logging} >>> Object>>logCrTab: {logging} >>> >>> Of course the simplest way how to fix that is revert previous versions >>> of this methods. However we may use some more general solution where >>> ToolRegistry will be part of the kernel but then we will have to solve >>> questions what tools are default, what to do if the tool class is >>> missing etc. >>> >> >> Is 'Smalltalk' global name part of kernel? >> If so, then i think SmalltalkImage should be too and ToolRegistry. >> >> Tool registry is just a registry. It doesn't imposing the existance of >> one or another tool. >> If tool with given name is missing, then attempt to use it will lead for error. >> > > The question why to have registry for something what is not necessary. > Some applications may Â want to remove tools from the image so to place > tools support to the kernel is a regression. The only tool that is > required for the Kernel now is Transcript for some Compiler messages > etc. I think that there is one much better solution - to remove > Transcript dependency from the kernel and for such messages to use > UIManager (something like #log: or maybe better #logStream). > MorphicUIManager then will use Transcript. > There is SmalltalkImage>>logDuring: aMonadicBlock except that it logs to file, not to transcript. > -- Pavel -- Best regards, Igor Stasenko AKA sig.

Aug. 19, 2011

Re: [Pharo-project] Smalltalk tools transcript

by Pavel Krivanek

On Fri, Aug 19, 2011 at 1:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 19 August 2011 11:41, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> Igor changed some uses of "Transcript" to "Smalltalk tools >> transcript". Of course it is not bad idea however it has some >> unwelcome consequences - mainly it cannot work on images that have no >> tools and Pharo Kernel and most of derived images have no ToolRegistry >> at all. Currently it breaks Pharo Kernel job on CI server. >> >> Here are affected methods: >> >> Object>>crLog: {logging} >> Object>>log: {logging} >> Object>>logCr: {logging} >> Object>>logCrTab: {logging} >> >> Of course the simplest way how to fix that is revert previous versions >> of this methods. However we may use some more general solution where >> ToolRegistry will be part of the kernel but then we will have to solve >> questions what tools are default, what to do if the tool class is >> missing etc. >> > > Is 'Smalltalk' global name part of kernel? > If so, then i think SmalltalkImage should be too and ToolRegistry. > > Tool registry is just a registry. It doesn't imposing the existance of > one or another tool. > If tool with given name is missing, then attempt to use it will lead for error. > The question why to have registry for something what is not necessary. Some applications may want to remove tools from the image so to place tools support to the kernel is a regression. The only tool that is required for the Kernel now is Transcript for some Compiler messages etc. I think that there is one much better solution - to remove Transcript dependency from the kernel and for such messages to use UIManager (something like #log: or maybe better #logStream). MorphicUIManager then will use Transcript. -- Pavel

Aug. 19, 2011

Re: [Pharo-project] Smalltalk tools transcript

by Igor Stasenko

On 19 August 2011 11:41, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Igor changed some uses of "Transcript" to "Smalltalk tools > transcript". Of course it is not bad idea however it has some > unwelcome consequences - mainly it cannot work on images that have no > tools and Pharo Kernel and most of derived images have no ToolRegistry > at all. Currently it breaks Pharo Kernel job on CI server. > > Here are affected methods: > > Object>>crLog: {logging} > Object>>log: {logging} > Object>>logCr: {logging} > Object>>logCrTab: {logging} > > Of course the simplest way how to fix that is revert previous versions > of this methods. However we may use some more general solution where > ToolRegistry will be part of the kernel but then we will have to solve > questions what tools are default, what to do if the tool class is > missing etc. > Is 'Smalltalk' global name part of kernel? If so, then i think SmalltalkImage should be too and ToolRegistry. Tool registry is just a registry. It doesn't imposing the existance of one or another tool. If tool with given name is missing, then attempt to use it will lead for error. > -- Pavel -- Best regards, Igor Stasenko AKA sig.

Aug. 19, 2011