On Sun, 30 Dec 2007, IOhannes m zmoelnig wrote:
the implies a 2nd-order framework that evaluates the results of the
1st-order framework. i am not a cybernetic, so i don't know how to solve
the problem of testing the 2nd-order framework.
Make the whole framework instantiable. Then you can inst
Mathieu Bouchard wrote:
>
> I still don't know how you got there. Good for you that you found it
> from experience. I hope that it was a good experience, but if you keep
> it that much secret, there's no way I can relate to that experience.
i got there because magically all my tests passed (ev
Mathieu Bouchard wrote:
> On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote:
>
>> in practice i found it often simpler to write tests that only output a
>> result when they know that they have passed: you need to create far
>> less logic, which might minimize the chance to write buggy tests
>> (whic
On Mon, 24 Dec 2007, Martin Peach wrote:
OK, but that's not called tristate, and "dual-rail" usually means having two
power supplies (e.g. plus and minus 5V instead of just 5V).
I don't know, I only read that somewhere quickly, just to verbalise again
what I had learnt before and didn't remem
Mathieu Bouchard wrote:
> On Mon, 24 Dec 2007, Martin Peach wrote:
>> Mathieu Bouchard wrote:
>>> In most tristate electronics, the third state is WAIT,
>> In digital electronics the third state is high-impedance, that is, it
>> is not driven high or low. However, a device reading a Hi-Z output
>
On Mon, 24 Dec 2007, Mathieu Bouchard wrote:
In most tristate electronics, the third state is WAIT,
I wasn't clear enough. There are tristate electronics that involve 3 kinds
of outputs but only 2 kinds of inputs, so this is really just binary logic
in which the 3rd state ("not connected") i
On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote:
in practice i found it often simpler to write tests that only output a
result when they know that they have passed: you need to create far less
logic, which might minimize the chance to write buggy tests (which i
found is inevitable) likewise, it i
On Mon, 24 Dec 2007, [EMAIL PROTECTED] wrote:
Quoting Mathieu Bouchard <[EMAIL PROTECTED]>:
I think that pretty much anyone doing automated tests so far agree that
it's better to have just all tests be written in the positive way, so
that you don't have to ever exchange the meanings of PASS and
On Mon, 24 Dec 2007, Martin Peach wrote:
Mathieu Bouchard wrote:
In most tristate electronics, the third state is WAIT,
In digital electronics the third state is high-impedance, that is, it is not
driven high or low. However, a device reading a Hi-Z output will
itself always output either 0 or
Quoting Mathieu Bouchard <[EMAIL PROTECTED]>:
> On Sun, 23 Dec 2007, Hans-Christoph Steiner wrote:
>
>>> e.g. "fail_blabla" will only success if it returns the state "FAIL"
>>> immediately or after a "WAIT".
>> In a binary system, anything that doesn't success would be a
>> failure. I don't qui
Quoting Mathieu Bouchard <[EMAIL PROTECTED]>:
> On Sun, 23 Dec 2007, IOhannes m zmoelnig wrote:
>
- allow fail-tests which have to return FAIL-state in order to success
>>> How do you know that a method has failed properly?
>> because it returns the expected FAIL-state.
>
> Why do you need th
Mathieu Bouchard wrote:
> On Sun, 23 Dec 2007, Hans-Christoph Steiner wrote:
>
>>> e.g. "fail_blabla" will only success if it returns the state "FAIL"
>>> immediately or after a "WAIT".
>> In a binary system, anything that doesn't success would be a failure.
>> I don't quite get the WAIT state. D
On Sun, 23 Dec 2007, Hans-Christoph Steiner wrote:
e.g. "fail_blabla" will only success if it returns the state "FAIL"
immediately or after a "WAIT".
In a binary system, anything that doesn't success would be a failure.
I don't quite get the WAIT state. Do you have an example of where to
use
On Sun, 23 Dec 2007, IOhannes m zmoelnig wrote:
- allow fail-tests which have to return FAIL-state in order to success
How do you know that a method has failed properly?
because it returns the expected FAIL-state.
Why do you need this instead of having a test PASS when the test checks
that
Hans-Christoph Steiner wrote:
>
>
> In a binary system, anything that doesn't success would be a failure. I
> don't quite get the WAIT state. Do you have an example of where to use
> that?
how do you test objects that need time (e.g. test [delay 1000])
i found it much more easy to write tes
On Dec 23, 2007, at 3:53 AM, IOhannes m zmoelnig wrote:
> Mathieu Bouchard wrote:
>> On Sat, 22 Dec 2007, IOhannes m zmoelnig wrote:
>>
>>> - keep the tests as simple as possible, but not simpler
>>> one should be able to write a test fairly easily; i think
>>> shortcuts are
>>> most likely not
Mathieu Bouchard wrote:
> On Sat, 22 Dec 2007, IOhannes m zmoelnig wrote:
>
>> - keep the tests as simple as possible, but not simpler
>> one should be able to write a test fairly easily; i think shortcuts are
>> most likely not needed most of the times (e.g. iirc, matju introduced
>> several shor
On Sat, 22 Dec 2007, IOhannes m zmoelnig wrote:
- keep the tests as simple as possible, but not simpler
one should be able to write a test fairly easily; i think shortcuts are
most likely not needed most of the times (e.g. iirc, matju introduced
several shortcuts in his unity-test frameworks to
Hans-Christoph Steiner wrote:
> On Dec 21, 2007, at 10:30 AM, IOhannes m zmölnig wrote:
>
>> Mathieu Bouchard wrote:
>>> On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:
What we really need is regression testing, I think that would
make it
easier to convince Miller to accept pat
On Dec 21, 2007, at 10:30 AM, IOhannes m zmölnig wrote:
> Mathieu Bouchard wrote:
>> On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote:
>>> What we really need is regression testing, I think that would
>>> make it
>>> easier to convince Miller to accept patches, and would be a great
>>> tool fo
20 matches
Mail list logo
