On Mon, 02 Sep 2013 13:01:20 +0200
David Majda <[email protected]> wrote:

> Dne 2.9.2013 12:29, Josef Reidinger napsal(a):
> > Well, I play a bit with minitest and must say that it contain bunch
> > of functionality, but there is two really annoying things about it.
> >
> > 1) It mocking mechanism - it is limited to be used only in block,
> > so it cannot be used in before stage
> 
> To clarify the impact: This means that tests with mocks would contain 
> duplicate code. Of course, this could be avoided by using some custom 
> mocking framework, like Mocha [1], but:
> 
>    1. There can be integration issues between Mocha and minitest, so
>       this combo would need to be tested first.
> 
>    2. The main advantage of minitest -- being included in Ruby stdlib
> -- would be lost, as we would be dependent on Mocha too.
> 
> I should add that RSpec already contains a mocking framework, very 
> similar to Mocha. It works well in my experience (I used it on
> multiple projects).
> 
> > 2) output of spec-style writing. In fact it just translate it into
> > test/unit tests and output is quite horrible compared to rspec.
> 
> Could you provide an example output?

yes. it is at http://pastebin.com/W3Hyjn0k .
To describe failing test, It in `describe "Yast::IP"` in `describe
"when told to check IPv6"` and test has generated name ( I generate it,
because I have there set of various ipv6 addresses ) `it "return true
for valid IPv6 '#{valid_ip6}'" do` and valid_ipv6 has changed value
( by my, to really fail - "1:2:3:4:5:68888888:127.0.0.1". Code is at [1]

BTW This is actually work-around. I like to have return true for valid
ipv6 and have there list of various ipv6, but then it doesn't write
value of ipv6 and return only `expect true, returned false`, which is
useless when test fail.

[1]
https://github.com/yast/yast-yast2/blob/master/library/types/test/ip_test.rb#L73

> 
> One thing I value on RSpec is the --format=documentation output:
> 
>    http://ascii.io/a/5272
> 
> This allows one to see specs in structured way, which makes it easier
> to spot organization & clarity issues, refactor & restructure the
> specs, etc. And it serves as a documentation of capabilities of the
> tested classes (if one writes the spec descriptions well).
> 

yes, looks quite nice.

Josef

> [1] http://gofreerange.com/mocha/docs/
> 


-- 
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to