Hi
I'm creating some tests for the decompiler (inspired by the one in SystemDictionary) and they are realllllly slow. So I'm thinking to create some kinds of SlowTestCase that could be turned off/on on demand. But I would like to know if someone already proposed a solution to that problem.
Stef
On Sep 24, 2004, at 3:12 PM, stéphane ducasse wrote:
I'm creating some tests for the decompiler (inspired by the one in SystemDictionary) and they are realllllly slow. So I'm thinking to create some kinds of SlowTestCase that could be turned off/on on demand. But I would like to know if someone already proposed a solution to that problem.
I think this is pretty common with unit tests... we had a similar situation where I used to work. I think we ended up just having a different test suite for the slow tests, and they were run nightly, instead of being run whenever you checked in code. But having a SlowTestCase class might be an okay way to handle it too.
There are some other slow tests already in the Squeak tests which should probably be moved to a separate batch of tests which don't have to be run as often. (such as the PNG tests, they seem quite slow) Although there may be a few slow tests which exercise a really important/broad area of Squeak, which you'd want to keep with the regular tests.
- Doug
On Oct 3, 2004, at 7:57 PM, Doug Way wrote:
On Sep 24, 2004, at 3:12 PM, stéphane ducasse wrote:
I'm creating some tests for the decompiler (inspired by the one in SystemDictionary) and they are realllllly slow. So I'm thinking to create some kinds of SlowTestCase that could be turned off/on on demand. But I would like to know if someone already proposed a solution to that problem.
I think this is pretty common with unit tests... we had a similar situation where I used to work. I think we ended up just having a different test suite for the slow tests, and they were run nightly, instead of being run whenever you checked in code. But having a SlowTestCase class might be an okay way to handle it too.
And on the flip side, it might be nice to have a QuickTestCase too, that can be run all the time - like, every time you accept a method...
Avi
On Oct 3, 2004, at 8:06 PM, Avi Bryant wrote:
On Oct 3, 2004, at 7:57 PM, Doug Way wrote:
On Sep 24, 2004, at 3:12 PM, stéphane ducasse wrote:
I'm creating some tests for the decompiler (inspired by the one in SystemDictionary) and they are realllllly slow. So I'm thinking to create some kinds of SlowTestCase that could be turned off/on on demand. But I would like to know if someone already proposed a solution to that problem.
I think this is pretty common with unit tests... we had a similar situation where I used to work. I think we ended up just having a different test suite for the slow tests, and they were run nightly, instead of being run whenever you checked in code. But having a SlowTestCase class might be an okay way to handle it too.
And on the flip side, it might be nice to have a QuickTestCase too, that can be run all the time - like, every time you accept a method...
Hey, neat idea ... I got to put that on my todo list for BrowseUnit ;-)
Romain
Avi
Actually the latest one is based on services, and there is a something to have services on OmniBrowser, so it should work out of the box ;-) ...
The problem is that OmniBrowser has evolved a bit since, so the code might not be up to date ... but I will rework on that soon.
Romain
On Oct 4, 2004, at 4:06 PM, Avi Bryant wrote:
On Oct 4, 2004, at 4:04 PM, Romain Robbes wrote:
Hey, neat idea ... I got to put that on my todo list for BrowseUnit ;-)
Is a version of BrowseUnit based on OmniBrowser also on the todo list?
Avi
Hi Romain,
And on the flip side, it might be nice to have a QuickTestCase too, that can be run all the time - like, every time you accept a method...
Hey, neat idea ... I got to put that on my todo list for BrowseUnit ;-)
So do you plan to connect that QuickTestCase - I think I call it one-method test ;-) - to the method under test?
A one-method test is dedicated to one method and, as it is _explicitly_ linked to that method, could be executed as soon as this method is changed/saved.
The most lightweight solution to explicitly create this link (I can think of ), would be to denote _the method under test_ in the test using a comment just before the call of the method under test: (here "test")
Example: =========== AccountTest >> testWithdrawOkFrom123 "setup" |anAccount | anAccount:= AccountTest new testDeposit100On123.
"test" anAccount withdraw: 60.
"asserts" self assert: anAccount balance = 40.
^anAccount =========== This is one part of the story. Another is, that tests could be composed, so that if its tests are called by other tests, this other tests should be executed:
In the example above only "AccountTest >> testWithdrawOkFrom123" would be executed if I changed "Account >> deposit", as it calls "AccountTest >> testDeposit100On123", which _is_ focusing on "Account >> deposit".
So composed tests should be a QuickTestCase for all explicitly linked methods.
Or do you plan to denote the tests in the method itself? I would prefer not, as you might run into problems with people who still :-) want to see their code independent of their tests, and who also want to rename a method without having to change the RefactoringBrowser, so that RB took denoting comments into account. (Above I can only use "test" and _not_ any name of a method to denote it...)
Actually I have some weeks to do a prototype for an Oopsla workshop with the nice name: "Revival of Dynamic Languages" and I would like to use services and browse-unit. Would you mind if I did it? Or do you have other design issues / solutions in mind I should know about?
My paper can be found on http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Gaelli.pdf
Thanks a lot for your very nice work on Services and BrowseUnit.
Cheers,
Markus
Hi Markus,
Actually I have no plan yet on how to implement this fonctionality ... this was just a fast reaction to Avi's idea. I know I have some code to link tests and methods, and I have to experiment with your approach too.
Concerning your proposal for the workshop, I'll be very glad if you use it ;-). Anyway the license is MIT I believe, so you could do whatever you want ;-). Keep me informed of the results.
Cheers, Romain
Markus Gaelli a écrit:
Hi Romain,
And on the flip side, it might be nice to have a QuickTestCase too, that can be run all the time - like, every time you accept a method...
Hey, neat idea ... I got to put that on my todo list for BrowseUnit ;-)
So do you plan to connect that QuickTestCase - I think I call it one-method test ;-) - to the method under test?
A one-method test is dedicated to one method and, as it is _explicitly_ linked to that method, could be executed as soon as this method is changed/saved.
The most lightweight solution to explicitly create this link (I can think of ), would be to denote _the method under test_ in the test using a comment just before the call of the method under test: (here "test")
Example:
AccountTest >> testWithdrawOkFrom123 "setup" |anAccount | anAccount:= AccountTest new testDeposit100On123.
"test" anAccount withdraw: 60.
"asserts" self assert: anAccount balance = 40.
^anAccount
This is one part of the story. Another is, that tests could be composed, so that if its tests are called by other tests, this other tests should be executed:
In the example above only "AccountTest >> testWithdrawOkFrom123" would be executed if I changed "Account >> deposit", as it calls "AccountTest >> testDeposit100On123", which _is_ focusing on "Account >> deposit".
So composed tests should be a QuickTestCase for all explicitly linked methods.
Or do you plan to denote the tests in the method itself? I would prefer not, as you might run into problems with people who still :-) want to see their code independent of their tests, and who also want to rename a method without having to change the RefactoringBrowser, so that RB took denoting comments into account. (Above I can only use "test" and _not_ any name of a method to denote it...)
Actually I have some weeks to do a prototype for an Oopsla workshop with the nice name: "Revival of Dynamic Languages" and I would like to use services and browse-unit. Would you mind if I did it? Or do you have other design issues / solutions in mind I should know about?
My paper can be found on http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Gaelli.pdf
Thanks a lot for your very nice work on Services and BrowseUnit.
Cheers,
Markus
I also did a sharedSetupTestCase for our application because the setup were long and repeated over and over and I could not solve that with a resources.
Stef
On 3 oct. 04, at 19:57, Doug Way wrote:
On Sep 24, 2004, at 3:12 PM, stéphane ducasse wrote:
I'm creating some tests for the decompiler (inspired by the one in SystemDictionary) and they are realllllly slow. So I'm thinking to create some kinds of SlowTestCase that could be turned off/on on demand. But I would like to know if someone already proposed a solution to that problem.
I think this is pretty common with unit tests... we had a similar situation where I used to work. I think we ended up just having a different test suite for the slow tests, and they were run nightly, instead of being run whenever you checked in code. But having a SlowTestCase class might be an okay way to handle it too.
There are some other slow tests already in the Squeak tests which should probably be moved to a separate batch of tests which don't have to be run as often. (such as the PNG tests, they seem quite slow) Although there may be a few slow tests which exercise a really important/broad area of Squeak, which you'd want to keep with the regular tests.
- Doug
squeak-dev@lists.squeakfoundation.org