Smalltalk › Redline Smalltalk

Basic test harness in place

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

SeanTAllen

Basic test harness in place

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.

Lee Breisacher-2

Re: Basic test harness in place

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

James Ladd

Re: Basic test harness in place

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

SeanTAllen

Re: Basic test harness in place

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

SeanTAllen

Re: Basic test harness in place

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?

James Ladd

Re: Basic test harness in place

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?
>

SeanTAllen

Re: Basic test harness in place

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?
>

Lee Breisacher-2

Re: Basic test harness in place

In reply to this post by SeanTAllen

Sean, why is Test.st under src/smalltalk rather than under test/smalltalk? Just curious...

Lee

James Ladd

Re: Basic test harness in place

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

Lee Breisacher-2

Re: Basic test harness in place

Oops, I wrote that wrong. What I meant was TestCase.st! Seems like it should be under src/test instead of src/main.

Robert Roland

Re: Basic test harness in place

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.

SeanTAllen

Re: Basic test harness in place

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.