Basic test harness in place

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Basic test harness in place

SeanTAllen
In the test directory you will find:

TestRunner.st

This is run on each maven build. 
It doesn't do anything very interesting right now. It just runs the TestSuite.

If you need to add tests, 

You will want to create a new one like:

TestCase < #MyClassTest

Then modify TestSuite.st thusly:

- run
  ArrayTest new; test.
  BooleanTest new; test.
  IntegerTest new; test.
  MyClassTest new; test.

You can look at IntegerTest.st for a decent example of use.

Overall, 
It is simple. It can be improved. It serves the purpose for now.

Right now

ArrayTest
BooleanTest
IntegerTest

are the 3 that exist. 

More coverage can be added to those, plus all the uncovered classes and methods.

Have at it and be sure to open issues that the tests might bring up ( I opened a couple tonight ).

-Sean-
p.s. yes TestCase is pretty worthless right now, but it will have functionality added to it.
Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

Lee Breisacher-2
Sean, thanks for getting this going. Looking good. Some comments:

1. Perhaps Assertion>assert: should be called assertTrue:. And then there's room for assertFalse:, assertNil:, etc. like JUnit. 

2. I'd like to see things like assertEquals:

+ assertExpected: expectedObject equals: aBlock
    expectedObject = aBlock value ifFalse: [ Object error: 'expected: ', expectedObject, ', but was: aBlock].

but alas, string concat doesn't work yet (chicken and egg problems, we'll probably see lots of that in the near term).

Lee
Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

James Ladd

Nice work Sean -   U not being able to sleep has big benefits for rl

On Saturday, December 24, 2011, Lee Breisacher <[hidden email]> wrote:
> Sean, thanks for getting this going. Looking good. Some comments:
> 1. Perhaps Assertion>assert: should be called assertTrue:. And then there's room for assertFalse:, assertNil:, etc. like JUnit. 
> 2. I'd like to see things like assertEquals:
> + assertExpected: expectedObject equals: aBlock
>     expectedObject = aBlock value ifFalse: [ Object error: 'expected: ', expectedObject, ', but was: aBlock].
> but alas, string concat doesn't work yet (chicken and egg problems, we'll probably see lots of that in the near term).
> Lee
Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

SeanTAllen
So has my being at home all day sick.

If we want to make lots of progress, everyone should move to NY and cough on me a lot.

On Fri, Dec 23, 2011 at 4:14 PM, James Ladd <[hidden email]> wrote:

Nice work Sean -   U not being able to sleep has big benefits for rl


On Saturday, December 24, 2011, Lee Breisacher <[hidden email]> wrote:
> Sean, thanks for getting this going. Looking good. Some comments:
> 1. Perhaps Assertion>assert: should be called assertTrue:. And then there's room for assertFalse:, assertNil:, etc. like JUnit. 
> 2. I'd like to see things like assertEquals:
> + assertExpected: expectedObject equals: aBlock
>     expectedObject = aBlock value ifFalse: [ Object error: 'expected: ', expectedObject, ', but was: aBlock].
> but alas, string concat doesn't work yet (chicken and egg problems, we'll probably see lots of that in the near term).
> Lee

Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

SeanTAllen
In reply to this post by Lee Breisacher-2

1. Perhaps Assertion>assert: should be called assertTrue:. And then there's room for assertFalse:, assertNil:, etc. like JUnit. 

Do you think assertNil and assertNotNil

should take an object or a block?

I'm leaning towards blocks unless someone has a good argument against it. 

2. I'd like to see things like assertEquals:

+ assertExpected: expectedObject equals: aBlock
    expectedObject = aBlock value ifFalse: [ Object error: 'expected: ', expectedObject, ', but was: aBlock].

but alas, string concat doesn't work yet (chicken and egg problems, we'll probably see lots of that in the near term).

Can you add an issue for the addition of that method so we don't lose track of it?

Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

James Ladd
Issues raised please

Plus I like the block argument. More flexible and consistent

On Saturday, December 24, 2011, Sean Allen <[hidden email]> wrote:
>>
>> 1. Perhaps Assertion>assert: should be called assertTrue:. And then there's room for assertFalse:, assertNil:, etc. like JUnit. 
>
> Do you think assertNil and assertNotNil
> should take an object or a block?
> I'm leaning towards blocks unless someone has a good argument against it. 
>>
>> 2. I'd like to see things like assertEquals:
>> + assertExpected: expectedObject equals: aBlock
>>     expectedObject = aBlock value ifFalse: [ Object error: 'expected: ', expectedObject, ', but was: aBlock].
>> but alas, string concat doesn't work yet (chicken and egg problems, we'll probably see lots of that in the near term).
>
> Can you add an issue for the addition of that method so we don't lose track of it?
>
Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

SeanTAllen
already went the other for non nil ones.

On Fri, Dec 23, 2011 at 4:29 PM, James Ladd <[hidden email]> wrote:
Issues raised please

Plus I like the block argument. More flexible and consistent


On Saturday, December 24, 2011, Sean Allen <[hidden email]> wrote:
>>
>> 1. Perhaps Assertion>assert: should be called assertTrue:. And then there's room for assertFalse:, assertNil:, etc. like JUnit. 
>
> Do you think assertNil and assertNotNil
> should take an object or a block?
> I'm leaning towards blocks unless someone has a good argument against it. 
>>
>> 2. I'd like to see things like assertEquals:
>> + assertExpected: expectedObject equals: aBlock
>>     expectedObject = aBlock value ifFalse: [ Object error: 'expected: ', expectedObject, ', but was: aBlock].
>> but alas, string concat doesn't work yet (chicken and egg problems, we'll probably see lots of that in the near term).
>
> Can you add an issue for the addition of that method so we don't lose track of it?
>

Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

Lee Breisacher-2
In reply to this post by SeanTAllen
Sean, why is Test.st under src/smalltalk rather than under test/smalltalk? Just curious...

Lee
Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

James Ladd
because framework and runtime classes that ship are in src/main/smalltalk.
You could delete src/test/smalltalk and still write programs

On Tue, Dec 27, 2011 at 6:05 PM, Lee Breisacher <[hidden email]> wrote:
Sean, why is Test.st under src/smalltalk rather than under test/smalltalk? Just curious...

Lee

Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

Lee Breisacher-2
Oops, I wrote that wrong. What I meant was TestCase.st! Seems like it should be under src/test instead of src/main. 
Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

Robert Roland
Well, TestCase really is a base library class, as anyone can write unit tests in the framework we're providing.

I could see the argument for not putting it there if we had something resembling Metacello, but we're not quite there yet.

  - Rob

On Tue, Dec 27, 2011 at 6:46 AM, Lee Breisacher <[hidden email]> wrote:
Oops, I wrote that wrong. What I meant was TestCase.st! Seems like it should be under src/test instead of src/main. 

Reply | Threaded
Open this post in threaded view
|

Re: Basic test harness in place

SeanTAllen
What Rob said. test is redline tests. TestCase will grow into something anyone can use.

Or at least that is my thinking.

On Tuesday, December 27, 2011 at 11:16 AM, Rob Roland wrote:

Well, TestCase really is a base library class, as anyone can write unit tests in the framework we're providing.

I could see the argument for not putting it there if we had something resembling Metacello, but we're not quite there yet.

  - Rob

On Tue, Dec 27, 2011 at 6:46 AM, Lee Breisacher <[hidden email]> wrote:
Oops, I wrote that wrong. What I meant was TestCase.st! Seems like it should be under src/test instead of src/main.