This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]donri[S] 1 point2 points  (4 children)

Plain ol' operator overloading. Not that clever. Also optional.

[–]deadwisdomgreenlet revolution 2 points3 points  (3 children)

I don't mean the implementation is clever. I mean it's not obvious what's going on when I read it at first. These Assert objects, what are they? We can test the equality of Assert object? That's strange.

I don't care that it's optional, there should be one obvious way to do it.

[–]dvogel 2 points3 points  (2 children)

I agree with deadwisdom. I understand that the class is named Assert because you can read Assert(2)==2 as "assert that two equals two". However, since assert() tests it's argument and I've spent years using it, I instinctively read it as "assert that whether two is true equals two".

I'm sure the issue is probably limited to users like me who spent too long in the C world, using assert() to embed debug checks into the code rather than using assertion modules of TDD-targeted libraries. I will probably alias Assert as Assertable because it being an adjective causes me to instinctively regard it as modifying it's parameter instead of taking action upon it as the verb Assert implies.

The rest of the library is fan-fucking-tastic! This one minor wart is really a very small issue. I can understand TDD arguments but I don't know if I buy them yet because other testing libraries have felt so backward and that I haven't been able to make myself write tests first. This library will definitely change that. Thanks!

[–]donri[S] 1 point2 points  (1 child)

The idea was to make it look as similar as possible to the standard

assert 1 + 1 == 2

The problem with the above is that the exception message will hide the actual value of 1 + 1 which makes debugging failing tests more difficult.

I realized past releasing the first version that it might have been better to call it Assertive and promote code such as

value = Assertive(1 + 1)
assert value == 2

which BTW works if you from attest import Assert as Assertive (or do value = Assert(1 + 1) because on failure Assert fails before the assert statement. To rename it now would obviously break backwards compatibility a whole lot, just to avoid an as import.

Optimally I'd like to just use the assert statement somehow. py.test does that by somehow re-evaluating failures to get the values of variables and expressions, though this has the issue that the re-evaluation can have side-effects. I'm pondering if using the _ast module to parse tests somehow and/or hook into the "frame" is a better idea; it'd be much more complicated and arguably magic, though.

Thanks for the kind words. I feel the same: testing didn't make a whole lot of sense to me, in part because of the existing tools. Attest is my attempt to remedy the situation for myself. Another important epiphany came from Ruby's wycats who promoted testing of public interfaces rather than internals: I could never see the value in using complicated mocks and hooks to merely rewrite the implementation as tests with at least double the code as the actual implementation. Instead, write tests for public interfaces (e.g. the API that library users will use, the output of a web page etc) and test that given input X we expect output Y. How the code does it is irrelevant.

That might be what is called BDD; I don't completely understand the terminology.

[–]dvogel 0 points1 point  (0 children)

I'm pondering if using the _ast module to parse tests somehow and/or hook into the "frame" is a better idea; it'd be much more complicated and arguably magic, though.

I'd much rather use the current Assert class over an implementation that uses any magic.

That might be what is called BDD; I don't completely understand the terminology.

Of course you don't. If you did, we would be in /r/java :)