On 2015-03-31 23:12, Atila Neves wrote:
I actually thought about the whole "it should fail to build if any of
the unit tests fail" idea 2 or 3 weeks ago, so this sounds good.
WRT to the error messages and their recognition by text editors, a
_massive_ improvement would be compiler-assisted formatting of the
assertion errors. This:
core.exception.AssertError@foo.d(2): Assertion failure
Is not useful when I wrote `assert(foo == 2)`. This, however, is:
tests.encode.testEncodeMoreThan8Bits:
tests/encode.d:166 - Expected: [158, 234, 3]
tests/encode.d:166 - Got: [158, 234]
In Python, my favourite testing framework is py.test. It reflects on the
test code itself and replaces `assert foo == 2` with its own code so
that it looks like this in the output:
def test_foo():
foo = 5
assert foo == 2
E assert 5 == 2
It also recognises things like `assert x in xs`, which is obviously
handy. Since Walter has mentioned the "specialness" of assert before,
maybe the compiler could recognise at least the most common kinds and
format accordingly (assert ==, assert in, assert is null, assert !is null)?
I kind of agree, RSpec has similar formatting of failed tests. But I
leaning to that this should be handled by a library. RSpec has a lot of
matchers (assertions) and supports custom matchers as well. For example,
for associative arrays RSpec will print a diff of the two objects.
For example, the following test:
describe 'Foo' do
it 'bar' do
{ foo: 3, bar: 4, baz: 5 }.should == { foo: 3, bar: 4, baz: 6 }
end
end
Will print the following failures:
Failures:
1) Foo bar
Failure/Error: { foo: 3, bar: 4, baz: 5 }.should == { foo: 3, bar:
4, baz: 6 }
expected: {:foo=>3, :bar=>4, :baz=>6}
got: {:foo=>3, :bar=>4, :baz=>5} (using ==)
Diff:
@@ -1,4 +1,4 @@
:bar => 4,
-:baz => 6,
+:baz => 5,
:foo => 3,
# ./spec/text_mate/helpers/options_helper_spec.rb:6:in `block (2
levels) in <top (required)>'
It also prints the comparison operator used.
--
/Jacob Carlborg
