开云体育

P.S. in the first sentence of that second paragraph I should have said you stub the method and assert something about the SUT, only. In other words: For a query: Arrange: stub the query and pass the

Are you familiar with Command Query Separation (CQS)? I've always found that the most coherent and useful way to explain why you would choose a mock or a stub. The most interesting thing about a

On Wed, Jan 15, 2014 at 12:56 PM, Mateusz ?oskot <mateusz@...> wrote: > > > On 15 January 2014 04:41, Adam Sroka <adam.sroka@...> wrote: > >> On Tue, Jan 14, 2014 at 5:31 PM, Mateusz

Yes, that is waht a general theory of (unit) testing says, but...devil's in the detail like classicists vs mockists ( http://martinfowler.com/articles/mocksArentStubs.html) I mean, lots of things

Sometimes I have test-driven a class, and then I can refactor the "private parts" of the class until it is almost entirely different than the original code, but the tests haven't changed. There may be

Right, that has been clear to me, in theory. Charlie, you've nailed exactly what I've misunderstood. Thank you very much. Best regards, -- Mateusz ?oskot, http://mateusz.loskot.net

Yes, by definition, because you are testing the way the "unit" works. It is necessarily coupled to the interface of the object you are testing, though not necessarily to its internals. If the test is

Unit tests _are_ about implementation at a certain level, and about interface at another. The difference is that we are talking about the "interface" of a class, which may be buried deep in the

Yes, I've come up to this conclusion after some time. Indeed, and that is a matter of my concern. I'm testing the implementation and somewhat implicitly I'm assuming this particular test verifies

"I could have replaced self.assertTrue(item_exists) with foo.xdep.get_item.assert_called_once_with(1)" These two things are not equivalent tests. your first assert, is correct and is testing the

I'm re-reading my own post and realising, aren't 2) and 3) breaking the guideline [1] about writing tests to the interface, not the implementation? I think the original version of

Hi, I'd like to ask for ideas of best practices in case of developing and testing a wrapper for a Python legacy module. Especially, about applying the single assert / single mock rule which I have

Wow, I had missed that blog post. Fascinating. Thanks! R Ron Jeffries www.XProgramming.comPerfectionism is the voice of the oppressor -- Anne Lamott

Missed the original post ... so many thanks for sharing! Wish this group were more active.

Pity I didn't see this blog post first.... http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html Because then I would have defined "Provocative Test that adds one

#likedthispost

So I have being doing TDD for years now. But I started noting I tend not to do it exactly "By The Book". So as an exercise I tried going back to doing it... * Very fine grained steps. * Small

Hi All. I hope this isn't spamming the list, but I could not think of a better suited place to post. I'm looking for a job and I would love to hear from you if you live in a place warmer than Norway

Dear IT manager/project manager/developer, We are two software engineering research groups working on improving methodologies and practices for Web development. We kindly ask you to

Please trim down posts. A long thread does not require emails of increasing length. Try to quote only the material you need, and trim the rest. Thanks, Ron Jeffries www.XProgramming.com Don't ignore