开云体育

Hello! I'm new to TDD and this group. For practice, I started a simple project and now I want to create a list of random strings, but such that no two strings are ever the same. In a very unlikely,

Whoops just saw yesterday's message came in all garbled.. here it is again properly formatted.. ========================== Hi again Gishu and all, Seems like this thread has grown since

Hi again Gishu and all, Seems like this thread has grown since I last looked :) What I used to do in this case is inject the disposable object as a collaborator (interface representing its role) into

Nope. I did test-drive this design. The connection instance represents an open connection to a hardware device. All conn parameters appear as constructor parameters of this type - one of which is a

Yes, +1 to that. I’ve been wondering what the business or functional need was that was driving that particular implementation and whether it might have been done differently. And for sure it would

Hi Gishu Sorry if my reply is out of context - I've been having trouble finding all the replies in the new (?) Yahoo group UI.... In general - the idea is the tests drive your design. Here it

AHA! But then a factory should not be using the objects it creates.... :) Sent: Monday, February 03, 2014 8:40 AM To: testdrivendevelopment@... Subject: RE: [TDD] How do I unit test a

Unless it's a factory

I agree, my point is that you should ALWAYS be given the object rather than it belonging to you. Therefore, the whole IDisposable pattern seems flawed from a design perspective. All that said, you

...except, if you're given the object rather than creating it yourself, then its lifetime doesn't belong to you, and you don't need to be concerned with whether it's

If A cares about this specific property it would require B to implement IDisposable. From A's perspective, it is given an object of type B to perform a specific action. B would be available to A

Amir, I feel like I might be missing your point. Why is it unreasonable for A to know that B uses expensive resources and provides a way to release them early? Surely this was one of

Except that B must already be IDisposable. The IDisposable pattern requires that any object that owns an IDisposable must itself implement IDisposable. * This is inane, as it requires the owning

I disagree. All that A needs to know is that B implements the IDisposable interface. The only reason to ever call Dispose() is to initiate an early release of expensive internal resources. If the

I agree that it is difficult. Here is the test list that I used: - when the Finalizer is called it releases all unmanaged resources - when the Finalizer is called it does NOT Dispose its

Except that B must already be IDisposable. The IDisposable pattern requires that any object that owns an IDisposable must itself implement IDisposable. n This is inane, as it requires the owning

Except that B must already be IDisposable. The IDisposable pattern requires that any object that owns an IDisposable must itself implement IDisposable. I agree completely. My original point was

This only applies to objects that it owns. Otherwise if it dispose of a reference that has been passed to it (say through injection) then it may be closing an object that is still required

That is what I thought. So I object A uses B and C and C (and A) are IDisposable, we need to ascertain that C's Dispose is called, right? Note, however, that the fact that A uses B and C, is an

Sorry - hit send too early: It depends. If its Dispose() method has been called (its owner has requested early release of its resources), then it is required to call Dispose() on all of its