On Wed, Feb 25, 2009 at 4:59 PM, Michael Koziarski <mich...@koziarski.com> wrote: > >> That sounds like a job for forking. > > That makes accumulating the failures from the child process > essentially impossible though, you'd end up with crazy output > intertwined with the parent process.
My assumption was that we would create a pipe before forking, each of the two processes would close one end of the pipe and talk into the other, and pass back the output/status. The parent would check that it matches (assert_equal "everything worked" line_read_from_pipe). But I think forking doesn't really work on Windows (haven't tried, but it's certainly hard to implement for other languages so I imagine it doesn't work in Ruby either). But, this is all a problem with spawning in general, so if we do go with spawning/forking as suggested, testing on Windows would get quite difficult. Anyway, I'm just saying that forking would be better than spawning in general. As for whether this is the 'right' way to test Rack integration etc. - I'm not sure we can solve the problem all neatly wrapped up inside the test harness, personally. We might just have to deal with it at a higher level - having multiple continuous integration targets, one with each different thing we need to test against. We don't have to run the full test suite for each, and many could live on the same server with a bit of coaxing. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
