Denis Kudriashov wrote
Problem with TestCase approach is mixing two separate concerns. First is
how we want to define system specifications. Another is how we can persist
such specifications.
...
So it is my vision. I really want to build such system but I have no time
for this yet.
Maybe
On Dec 4, 2013, at 5:18 AM, Dennis Schetinin chae...@gmail.com wrote:
This is the task I would really like to participate in. Although, just as
you, I have no time at all, I still will find at least few hours a week :)
welcome to our nice club of busy people
Sean P. DeNigris wrote
Are you interested in integrating my changes into the current API? If so,
I'll refactor them and clean them up. I personally would find it difficult
to use the library without them. Coming from Ruby, a proper test double
framework is the thing I miss most. Rspec was
On 4 December 2013 10:01, Attila Magyar m.magy...@gmail.com wrote:
Sean P. DeNigris wrote
Are you interested in integrating my changes into the current API? If so,
I'll refactor them and clean them up. I personally would find it difficult
to use the library without them. Coming from Ruby, a
The reason for my initial hesitation was that... in rspec, it is easy to stub
out global class objects and... I don't think this is the right solution for
the problem.
Ha ha, you were right to be cautious. I've been thinking for offer a year about
how to do that without method wrappers. But I
On 4 December 2013 11:34, Sean P. DeNigris s...@clipperadams.com wrote:
The reason for my initial hesitation was that... in rspec, it is easy to
stub out global class objects and... I don't think this is the right
solution for the problem.
Ha ha, you were right to be cautious. I've been
I'll try.
I think mocking the file system and other third party, low abstraction
stuffs can lead brittle tests and duplications.
For example we want to store certificate files in pem format in the file
system.
Mocking out the fs would look like this:
file = mock('file')
Sean P. DeNigris wrote
I understand the motivation. My question is how do we create appropriate
hooks so that we don't get into these conflicts?
I don't know yet, I'm open for discussion.
Sean P. DeNigris wrote
- anyArgument now inst var of BabyMockTestCase, similar to BmAnyMessage
How do
2013/12/3 Dennis Schetinin chae...@gmail.com
I see the only correct way to build a good testing environment: tests should
be basically objects, not methods.
They are objects. Instances of TestCase.
But for simplicity they're implemented in a single factory class,
the TestCase subclass...
Sure, there are objects: it's Smalltalk, methods are obects too :) That's
really correct: SUnit is the simplest thing that (still) works. But is it
still enough? Isn't it a time to make more steps and improve?
I just mean it would be great to have test as distinct object that I can
explore, add
Attila Magyar wrote
did you want something like this?
mock a: anyArgument b: exactArgument1 c: exactArgument2
Exactly.
Attila Magyar wrote
I rarely use
/
does
/
, as far as I remember it is not even documented. I don't know the code
behind the test but based on the names it looks like an
Problem with TestCase approach is mixing two separate concerns. First is
how we want to define system specifications. Another is how we can persist
such specifications. When we stay at test case level we lost freedom for
specification definition. We restricted with smalltalk language artifacts.
Sean P. DeNigris wrote
In fact, #does: and #answers: could easily be merged, using double
dispatch to pass either a block or a value.
It's true, but it would make difficult to return a block. E.g.
mock can receive: #msg; answers: [ [..] ]
Sean P. DeNigris wrote
Unrelatedly, it would be
On Dec 3, 2013, at 2:43 PM, Attila Magyar [via Smalltalk]
ml-node+s1294792n4727144...@n4.nabble.com wrote:
It's true, but it would make difficult to return a block. E.g.
mock can receive: #msg; answers: [ [..] ]
I'll trade an extra pair of brackets in a less common case for a simpler
This is the task I would really like to participate in. Although, just as
you, I have no time at all, I still *will* find at least few hours a week :)
--
Best regards,
Dennis Schetinin
2013/12/3 Denis Kudriashov dionisi...@gmail.com
Problem with TestCase approach is mixing two separate
We have some cool matchers (Phexample, StateSpecs), some nice mocking
libraries (Mocketry, BabyMock), and Phexample's acknowledgement that tests
build on each other. The problem is, it's hard to cherry-pick and build
one's perfect test enviroment. For example:
- Phexample and Mocketry, whose
Sean P. DeNigris wrote
- Phexample and BabyMock both require subclassing from their own TestCase
subclass, so they can't be used together.
The reason for having the base class is to verify the expectations at the
end of the tests automatically. Doing this manually is possible (context
I see the only correct way to build a good testing environment: tests
should be basically objects, not methods.
--
Best regards,
Dennis Schetinin
2013/12/3 Sean P. DeNigris s...@clipperadams.com
Attila Magyar wrote
The reason for having the base class is to verify the expectations at
18 matches
Mail list logo
