Issue #21 new

Spec differnt ways of failure and create a systest.

Samuel Ytterbrink
created an issue

The unittest framework differentiate errors from failure.

Maybe we should too, thats why i don't implement the test right away.

In pytddmon we could have(and find) 3 different type of errors: test don't run (syntax error or exceptions outside test code). test has a error (a exceptions in the testcode). * the test fails (the criteria is not fulfilled).

Maybe we should translate this in to not just red and green, orange maybe?

When this is decided we should create a test for it and then implement it accordingly.

Alos speaking in terms of reds instead of greens would make the program easier to implement and then we could also talk about oranges and so on.

Comments (2)

  1. Olof Bjarnason repo owner

    So far pytddmon has a quite simple technique to decide which color to use: all tests pass, then green, otherwise red.

    That is easy both implementationwise and to the user of pytddmon.

    (There is a third state (gray), which means the number of tests decreased, but I'm not actually sure it works anymore.)

    If we introduce more colors/states, we want a really simple rule to follow. For example, show the "most severe" error first: if there is one red and one orange tests (whatever the two means), color pytddmon red.

    UPDATE. There is an even more severe problem with adding lots of colors: it breaks the Red-Green-Refactor idiom of TDD. On the other hand, other graphical unit testing tools already do this. For example the GUI runner in NUnit, which has several states (and I always forget what color means what, except for red and green..)

  2. Log in to comment