Thanks, guys. I'll try and respond the best I can to everything I've read:<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>examples/test_sclara.py line 14:</span><br style><br style><span style> with test('does not have access to inner setup context') as context:</span><br style><span style> try:</span><br style><span style> context.bar</span><br style>
<span style> except AttributeError:</span><br style><span style> pass</span><br style><br style><br style><span style>Will this fail if no AttributeError is thrown?</span></blockquote><div><br></div><div>Good point. That should probably raise an AssertionError if no AttributeError is thrown to show that it worked when it shouldn't have. </div>
<div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>And line 45:</span><br style><br style><span style> with test('has access to inner setup context') as context:</span><br style><span style> assert context.foo == 'bar'</span><br style><br style>
<span style> with test('has access to outer setup context') as context:</span><br style><span style> assert context.bar == 'foo'</span><br style><br style><span style>Shouldn't "inner" and "outer" be swapped here?</span><br style>
<span style>The outer setup adds foo and baz attributes.</span><br style><span style>The inner setup adds the bar attribute to the context and changes the baz value.</span></blockquote><div><br></div><div>I'll make sure to fix that. Thanks.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style>It might be heretic to raise this in a testing list for Python, but I also believe that the Python community</div><div style>is not as pro-innovation in the testing environment as other communities are, which is detrimental to the fact</div>
<div style>that there are a few people who don't like the standard testing framework and are looking forwards to an</div><div style>alternative.</div></blockquote><div><br></div><div>I get this feeling, too; not sure how to remedy this (assuming it's an actual problem). </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p class="MsoNormal" style><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hmm – I am thinking that a python dsl similar to JS’s Jasmine with matchers would be doable.<u></u><u></u></span></p>
<p class="MsoNormal" style><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal" style><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">with describe(“foo”):<u></u><u></u></span></p>
<p class="MsoNormal" style><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> It(“should throw bar”):<u></u><u></u></span></p><p class="MsoNormal" style><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> expect( lambda : foo.doStuff()).toRaise(BarException);</span></p>
</blockquote><div><br></div><div>The more I thought about this the more I liked it. You could probably push an API like this as a tool to be used regardless of what testing framework you're using. If it was pluggable, I think you might have something pretty powerful.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>I've never seen the value in ladling English all over my test cases. How is your code better than what you can currently do with unittest?:</span><br style><br style><span style> def test_should_throw_bar(self):</span><br style>
<span style> """foo should throw bar"""</span><br style><span style> with self.assertRaises(</span><span style>BarException):</span><br style><span style> foo.doStuff()</span></blockquote>
<div><br></div><div>Personally, I just hate writing method names while testing. I hate it. It makes me think like a programmer at exactly the wrong time. At that point in time, I want to be thinking abstractly about the system under test and what it is that it is supposed to do. When I'm using classes and methods to do that, I'm doing OOP and it just pains me. Now, I'm not saying OOP is something never to do, but I don't want to do it there.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>Could that complexity be a code smell?</span><br style><span style>Given enough context every assertion could have a nice description. Or</span><br style><span style>couldn't they?</span></blockquote><div>
<br></div><div>I think that's kind of the goal. I'm pretty sure it's generally agreed upon that 1 assertion per test is generally what people mean when talking about unit tests and to have an english statement that is either true or false based on the outcome of that assertion is pretty neat (I think).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>I’ve then got first the basic device, the construction of which is one behaviour I’ve described. Then I have a constructed device, and all other tests apply to that. In those, I’ve the Locked behaviour, and the unlocked behaviour. The unlocked behaviour has the test for locking a device, and tests to ensure operations like unlocked, setting its state throw exceptions, while querying the state is permitted. The locked behaviour should permit setting state, still permit querying state, and permit unlocking – it should not allow the device to be locked again. These hierarchical behaviours share semantics, and also share setup/teardown (before/after) behaviour at different levels. Ie – setup for any mocks needed to construct the thing, setup a constructed object, and setup a locked object. Nesting could give a more expressive means of combination, thus meaning less duplication. I realise this could be done with helpers of other kinds – but I’ve seen in both a very brief and very clear test written this way.</span></blockquote>
<div> </div><div>Yes. This is exactly the idea. </div><div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>Interesting we had a discussion about a theoretical tool similar to this a while back.</span></blockquote><div><br></div><div>Hah. A lot of that is identical to what I had done at various stages during development; kind wild. </div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>How is this similar to or different than Lettuce?</span></blockquote><div><br></div><div>I believe Lettuce is based on Cucumber which claims to be an acceptance testing tool. It's meant to be quite a bit higher level than something like what I'm trying to do (which is more for unit testing) and probably best suited for more functional/integration testing. </div>
<div><br></div><div><br></div><div>Again, I appreciate the feedback and discussion. I'll keep hacking and keep you guys posted. Thanks!</div><div><br></div><div><br><div class="gmail_quote">On Mon, Mar 26, 2012 at 8:31 PM, Ned Batchelder <span dir="ltr"><<a href="mailto:ned@nedbatchelder.com">ned@nedbatchelder.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 3/24/2012 5:00 PM, John MacKenzie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://github.com/198d/sclara" target="_blank">http://github.com/198d/sclara</a><br>
<br>
I wrote this library based on a thought I had at the TiP BoF this year (hence the name "s(anta)clara"): RSpec for Python (unoriginal idea) written entirely with context managers (original idea, hopefully). I had been writing Ruby for 3 years up until about December of last year and have been writing Python full time since then. What I like most about RSpec is the way you define and organize tests. You end up grouping similar test cases in a sort of hierarchical manner (without resorting to OOP, which I hate the most about writing tests with unittest) and get things like cumulative setup/teardown from parent contexts while producing an english statement that is either true or false after the test is run. These are the main ideas I tried to capture with sclara. Context mangers, at first glance kind of make sense; if you make a quick sketch of what this might look like, you get something like this:<br>
<br>
with description('Our object under test'):<br>
with test('does something'):<br>
assert True<br>
with test('does something else'):<br>
assert True<br>
with description('when some condition is met'):<br>
with test('acts a specific way'):<br>
assert True<br>
<br>
</blockquote>
<br></div>
How is this similar to or different than Lettuce? Sorry, I have no experience with any of these rubyesque tools.<span class="HOEnZb"><font color="#888888"><br>
<br>
--Ned.<br>
</font></span></blockquote></div><br></div></div>