The obvious dirty fix for a lot of this dawned on me. I guess I did
not think of it earlier since I consider it bad style.

I will have to re-factor my controllers and components so that the 2-4
lines of code that uses curl (for example) get their own method. The
poor style IMHO being to re-factor simply to make testing easier and
not because it improved functionality or readability or anything else.
And of-course I could never write a test for those lines that I would
then need to capture in my test subclass. (They aren't many lines but
I'd still like to include them just to be complete)

I am going to give this approach a try. I would like a more complete
but this would take me a good way.

Funny how all tests depend on a single point. If I was to test a valve
I would put air or liquid into one end and see what happened at the
other end to determine how the valve worked. In code I find it
extremely difficult to "look at both ends".

Tanks for kick-starting my brain, Daniel.
:)



On Oct 2, 9:26 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi Daniel,
> I'm not sure that would get me very far. For SOAP it would be possible
> if I created a big mockup of nusoap, even though it looks pretty time-
> consuming. I don't know of a way to do the same with curl.
>
> Looking at the tests for EmailComponent I see that they are set up to
> listen on port 25. Problem is this does not at all work on my system
> (Mac) possibly because the os is using the same port. This is why I
> stopped looking at ways to capture outgoing requests and instead have
> tried to find a way to pretend to be the receiving end.
>
> For http the trouble begins at the stage of trying to setup a
> "fake" (or mock) recieving webserver inside my test case.
> If I just point the request to localhost (or projectname.site) any
> data sent wil be received by the "normal" app and database and not the
> test.
>
> It really would be enough for my needs to be able to
> assertEqual($expected_url, $actual_url_called) or
> assertTrue($fake_webserver->was_called)
> or something of that sort.
>
> On Oct 1, 4:02 pm, Daniel Hofstetter <[EMAIL PROTECTED]> wrote:
>
> > Hi Martin,
>
> > > I was wondering if anyone had some tips for a good way to write a test
> > > for a Controller or Component that performs an outgoing request?
> > > Ordinary models and things are so much more self-contained and
> > > therefore usually not a big problem writing tests for.
>
> > > In my case I a talking about a Component that performs SOAP calls to
> > > an "outside" server, a Controller that works like a router/gateway
> > > (incoming requests trigger calls to different sub-servers determined
> > > by the content of the request and a stored list of available sub-
> > > servers). It does this using simple curl.
>
> > > I would like to be able to write a test for these to determine of the
> > > correct SOAP-endpoint or http-address is contacted... without actually
> > > contacting them. I can configure the endpoints to be somewhere o
> > > localhost for the tests but I don't know how I would then make the
> > > testcase capture that request and compare it to my expected result.
>
> > > Another more common example would be an email-component where you
> > > might want to test if the correct SMTP is contacted without sending a
> > > bunch of emails.
>
> > Maybe you can solve it with mock 
> > objects:http://www.simpletest.org/en/mock_objects_documentation.html
>
> > Hope that helps!
>
> > --
> > Daniel Hofstetterhttp://cakebaker.42dh.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CakePHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to