BTW I like grey for a method that was edited in the debugger. Because red is not good. The proof is that when I rerun my test is green. While saying I do not know you have to rerun is a good solution. I like it.
I got always frustrated with the red. On Fri, Nov 24, 2017 at 12:05 AM, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Hi andrew > > I like your idea. > It is fun and at least we can spot test. > Now sometimes we will have to have self assert: true because running a > code can be also considered as a test. > Now what I do not like is empty test method because there are green. > > stef > > On Tue, Nov 21, 2017 at 10:07 PM, Prof. Andrew P. Black > <bl...@cs.pdx.edu> wrote: >> While we are discussing colors, what should we do about a test that does not >> make any assertions at all? >> >> A couple of years ago, a smart student who was working on a testing dialect >> for me decided that such tests should be in a new category all of their own. >> Later I simplified things and just made these tests fail. I am pretty >> convinced now that this is the right behaviour. It certainly suits my >> purposes (teaching TDD); if the student omits to make any assertions, they >> have a failing test. The message is: "Failure: test made no assertions". >> >> Currently, such a test is green in Pharo. In 2013, I filed a bug report on >> a bunch of tests of #printOn: on collections that made no assertions. (The >> test writer didn’t understand how streams worked, and made assertions for >> each element of the empty string.) I was reminded of this just this week, >> because those tests have yet to be fixed. I suspect that if they had been >> yellow, rather than green, then they would have been fixed before now. >> >> I plan to fix those tests on Friday, but I also wonder about changing the >> behaviour of the testing framework. What do you think? >> >> Andrew >> >>
