Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>MiniTest does implement <code>assert_nothing_raised</code> in its Test::Unit compatibility layer, but in its own tests (<code>MiniTest::Unit</code> and <code>MiniTest::Spec</code>) it does <em>not</em> implement any test like this. The reason is, the programmer argues, that testing for nothing raised is not a test of anything; you <em>never</em> expect anything to be raised in a test, except when you are testing <em>for</em> an exception. If an unexpected (uncaught) exception occurs in the code for a test, you'll get an exception reported in good order by the test and you'll know you have a problem.</p> <p>Example:</p> <pre><code>require 'minitest/autorun' describe "something" do it "does something" do Ooops end end </code></pre> <p>Output:</p> <pre><code>Run options: --seed 41521 # Running tests: E Finished tests in 0.000729s, 1371.7421 tests/s, 0.0000 assertions/s. 1) Error: test_0001_does_something(something): NameError: uninitialized constant Ooops untitled:5:in `block (2 levels) in &lt;main&gt;' 1 tests, 0 assertions, 0 failures, 1 errors, 0 skips </code></pre> <p>Which is exactly what you wanted to know. If you were expecting nothing to be raised, you didn't get it and you've been told so.</p> <p>So, the argument here is: do not use <code>assert_nothing_raised</code>! It's just a meaningless crutch. See, for example:</p> <p><a href="https://github.com/seattlerb/minitest/issues/70" rel="noreferrer">https://github.com/seattlerb/minitest/issues/70</a></p> <p><a href="https://github.com/seattlerb/minitest/issues/159" rel="noreferrer">https://github.com/seattlerb/minitest/issues/159</a></p> <p><a href="http://blog.zenspider.com/blog/2012/01/assert_nothing_tested.html" rel="noreferrer">http://blog.zenspider.com/blog/2012/01/assert_nothing_tested.html</a></p> <p>On the other hand, clearly <code>assert_nothing_raised</code> corresponds to some intuition among users, since so many people expect a <code>wont_raise</code> to go with <code>must_raise</code>, etc. In particular one would like to focus an <em>assertion</em> on this, not merely a test. Luckily, MiniTest is extremely minimalist and flexible, so if you want to add your own routine, you can. So you can write a method that tests for no exception and returns a known outcome if there is no exception, and now you can assert for that known outcome.</p> <p>For example (I'm not saying this is perfect, just showing the idea):</p> <pre><code>class TestMyRequire &lt; MiniTest::Spec def testForError # pass me a block and I'll tell you if it raised yield "ok" rescue $! end it "blends" do testForError do something_or_other end.must_equal "ok" end end </code></pre> <p>The point is not that this is a good or bad idea but that it was never the responsibility of MiniTest to do it for you.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload