Page 1 of 1

How to test this?

Posted: Thu Nov 27, 2008 11:51 pm
by alex.barylski
Regarding this disscussion:

viewtopic.php?f=19&t=91432

How do you test the two models? Considering one is *never* used independently...do I just test the results of the primary model knowing that it's secondary model is also tested. Or should I test the secondary model independently for the sake of atomicity?

Then would it make sense to have tests which test both consecutively to ensure synchronization/integrity???

Makes sense to test both independently...however I can see it being imporatnt to test them togather as well and yet see it being redundant... :P

What says you?

EDIT | Perhaps having them tested independtly as objects but consecutively within the same test, such as:

Code: Select all

testShouldCreateGroupsAssociatedWithRecord()
I would then create the primary model object, create the record and then create the groups thereafter and test they were refering to the same foriegn kets. The only problem is, this is effectively what I do in the primary model object when I create the groups using the array of groups passed into the createRecord() method...so the tests are redundant...ideas?

Cheers,
Alex

Re: How to test this?

Posted: Fri Nov 28, 2008 6:10 pm
by alex.barylski
Having that secondary model object is really causing me grief. :P

As it stands I have one test per method for the basic CRUD operations.

Code: Select all

testCreate()
{
  // 1. Create record and assert return value > 0
  // 2. Retreive record details and ensure they are the same as passed into create
  // 3. Reretive the list of groups associated with record and assert they are the same as those passed in 
}
While this might not be ideal...I see no other way (short of using mocks which I do not wish to do -- I think I epxlained hwy in T&D forum).

Suggestions?

Re: How to test this?

Posted: Fri Nov 28, 2008 8:28 pm
by josh
Well first off mocks != stubs, stubs are generally better, unless the real model is really simple or already implemented. If it's already implemented just use the real object, sure if you break that simple object tests that depend on it will fail but it will be relatively easy to see the source cause. Stubs are great from working "outwards in", coding the upper layers first and stubbing the lower layers
PCSpectra wrote:Having that secondary model object is really causing me grief. :P
If something is too difficult to test, it can be a sign the code "wants" to be structured differently

Re: How to test this?

Posted: Sat Nov 29, 2008 7:14 pm
by alex.barylski
Well first off mocks != stubs, stubs are generally better, unless the real model is really simple or already implemented
Hmmm...where did I imply otherwise? I am well awareof the differences, thanks. :P

Secondly to claim one is "better" even "generally" is naive. Neither is better, one is just more sufficient under certain situations. Considering you provided no circumstantial evidence of one being better or worse than the other. BTW there are mockists who would zealously argue with you until your ultimate death(s). :lol:
If something is too difficult to test, it can be a sign the code "wants" to be structured differently
Usually...but given the simple example I provided above and the fact no one has offered a better solution...I'm stuck believeing I have the ideal solution already. I'm more than happy to listen to how you might solve this problem...

Cheers,
Alex

Re: How to test this?

Posted: Sat Nov 29, 2008 11:21 pm
by josh
PCSpectra wrote:Hmmm...where did I imply otherwise? I am well awareof the differences, thanks. :P
Where did I imply you didn't know the difference? :P
Neither is better, one is just more sufficient under certain situations. Considering you provided no circumstantial evidence of one being better or worse than the other.
It depends if you consider encapsulation good then I guess.
BTW there are mockists who would zealously argue with you until your ultimate death(s). :lol:
Then theyre not doing TDD properly.
I'm more than happy to listen to how you might solve this problem...
You'd you have to give me more context, how about posting some use cases so I can give you my (non-sugar coated) opinion :wink:

Re: How to test this?

Posted: Sun Nov 30, 2008 2:22 am
by Eran
Usually...but given the simple example I provided above and the fact no one has offered a better solution...I'm stuck believeing I have the ideal solution already. I'm more than happy to listen to how you might solve this problem...
Yes, you provided very little information on why you need such a structure in the first place.

Re: How to test this?

Posted: Sun Nov 30, 2008 9:54 am
by josh
PCSpectra wrote:do I just test the results of the primary model knowing that it's secondary model is also tested. Or should I test the secondary model independently for the sake of atomicity?
It also depends if the "primary" model exercises all the branch points in the secondary model. For this you could look into code coverage but the only way to make sure it tests all the *bounds* and not just the branches is to write more tests. If you change the implementation of the primary object could it lead to the 'secondary' object being tested less?

Re: How to test this?

Posted: Sun Nov 30, 2008 10:45 am
by alex.barylski
It depends if you consider encapsulation good then I guess.
It's one of the cornerstones of OO development and when properly, it's invaluable, so yes IMHO it's a good thing. :P
Then theyre not doing TDD properly.
And how owuld you define TDD? Most BDD experts would probably argue that mock objects are a very important part of BDD and according to Dave Astels if your doing TDD right, you are already doing BDD. I would guess most people are doing TDD/BDD wrong.
You'd you have to give me more context, how about posting some use cases so I can give you my (non-sugar coated) opinion
A use case, something so simple? I think CRC cards would be more appropriate...but in anycase I may have explained it a little more clearly on SitePoint forums:

http://www.sitepoint.com/forums/showthread.php?t=586194

You can answer either here or there and I appreciate it :)

Cheers,
Alex

Re: How to test this?

Posted: Sun Nov 30, 2008 10:55 am
by josh
PCSpectra wrote:And how owuld you define TDD? Most BDD experts would probably argue that mock objects are a very important part of BDD and according to Dave Astels if your doing TDD right, you are already doing BDD. I would guess most people are doing TDD/BDD wrong.
Well mockists aren't doing TDD, I don't believe BDD necessarily means you have to use mocks, I don't know a lot about BDD though... you'd have to ask marguam the reaper or however the hell you spell his name :wink: .

I'd have to refer to you Fowler on that subject:
McGruff wrote:Fowler on integration v state-based testing Mocks aren't Stubs
hmm he writes
An important offshoot of the mockist style is that of Behavior Driven Development (BDD). BDD was originally developed by my colleague Dan North as a technique to better help people learn Test Driven Development by focusing on how TDD operates as a design technique. This led to renaming tests as behaviors to better explore where TDD helps with thinking about what an object needs to do. BDD takes a mockist approach, but it expands on this, both with its naming styles, and with its desire to integrate analysis within its technique. I won't go into this more here, as the only relevance to this article is that BDD is another variation on TDD that tends to use mockist testing. I'll leave it to you to follow the link for more information.
In that case then no, BDD is using whitebox not blackbox testing, which is doing TDD wrong in my opinion - because your tests specify the implementation, that defeats the psycological goals of TDD - TDD is driven development, it happens in the mind not in the computer... well tested coded is a side effect. I like the idea behind BDD though, instead of writing assert() this and that you write "this should do that". I'd like to hear from someone more knowledgeable wether or not BDD can implement "classical" testing instead of "mockist"

Re: How to test this?

Posted: Mon Dec 01, 2008 3:43 am
by Jenk
Mocks break encapsulation because you are no longer black boxing the object under test, as you are defining the implementation by using expectations. To expect is to define.

Mocks should be avoid where possible, but don't sweat it if you use them. Like everything in the software world, these are guidelines, not hard rules.

Dave Astel likes mocks and stubs a lot because what he uses for mocks, he also uses for stubs. They are very simple to produce, and make it very easy to not include unnecessary classes/objects into your tests/specs.

The mock framework he and a few others developed for Smalltalk and Ruby allow the easy/dynamic creation of stubs just as easily as mocks, or rather it should be said, both very, very easily. You don't even need to write a stub class.

BDD still encourages blackbox testing, probably more so than TDD (which was actually the primary reason Dave and chums wanted to evolve BDD, to get people focusing on Specifying Behaviour, rather than Testing Code.)