Improving portability of Spinach

32 views
Skip to first unread message

Luis Lavena

unread,
Mar 28, 2012, 8:25:53 PM3/28/12
to spina...@googlegroups.com
Hello,

I've been using Spinach with great success on both OSX and Linux, and
now we started to use it on Windows too.

But in order for me to feel confident about the tools I use across
platforms, I want to run tests/specs/features on them just to avoid
any potential cross-platform issue that later could be reported by
others.

Wanted to post here before I commit more time to the task and gather feedback.

I'm working right now in remove some components that do not play nice
across platforms: FakeFS and open4.

1) FakeFS: it uses symlinks which are not portable to current
implementation of Ruby for Windows.

I've seen "in_current_dir" helper for features, but not for tests,
I've used a similar helper on my own projects to remove the need of
FakeFS. My looking at the examples, nothing really complicated is done
with it, so implement a similar helper seems the best approach.

While I understand the need to avoid hitting the FS in the tests,
FakeFS has proven to be a difficult gem to make cross-platform
compatible.

2) open4 [1]

There are so many alternatives: popen4 [2], POpen4 [3] that my head is
spinning... not cross-platform, cross-platform,
too-many-dependencies...

Since Spinach is *only* 1.9, why not use Process.spawn & Process.wait2
instead? [4] [5]

- It is cross-platform
- It does not depend on external gem

The question remains if we need to propagate the exception that Open4
generates (like file not found and such)

Or maybe (most likely) I'm missing something.

Anyhow, wanted to check here with you guys before changing things around.

Thanks in advance for your time those who reached this point :-D

[1] http://rubygems.org/gems/open4
[2] http://rubygems.org/gems/popen4
[3] http://rubygems.org/gems/POpen4
[4] http://rubydoc.info/stdlib/core/1.9.3/Process.spawn
[5] http://rubydoc.info/stdlib/core/1.9.3/Process.wait2
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

Oriol Gual

unread,
Mar 29, 2012, 2:44:20 AM3/29/12
to spina...@googlegroups.com
Hi Luis,

I'm really happy that you're using Spinach :)

About the changes: +1 for me, I think we don't have strong opinions on FakeFS and open4. If there are better alternatives that make Spinach more compatible with Windows I'm in :)

Cheers.

Josep Jaume

unread,
Mar 29, 2012, 3:12:26 AM3/29/12
to spina...@googlegroups.com
Hi Luis,

Thank you very much for your feedback!

1) I agree with you in removing FakeFS. I've personally been using it in other projects and found out that is not that reliable. Like you said, you can't be sure the machine you're testing on actually complies to the API exposed by FakeFS. So +1 for using tmpdir!

2) I'm sure you're the expert on that matter :). I don't think we need to propagate the exceptions raised by Open4 - we just have to check the exit status of the process and its stderr and stdout. The thing is that the filesystem.rb library was extracted from Aruba (from the cucumber project), so maybe has a little more code than we really need - we didn't give it much thought. Thanks for pointing it out!

So, in conclusion, I think you're totally right with your points :). +1 for PR!

Thanks for all your help

Luis Lavena

unread,
Mar 29, 2012, 12:31:03 PM3/29/12
to spina...@googlegroups.com
On Thu, Mar 29, 2012 at 4:12 AM, Josep Jaume <josep...@gmail.com> wrote:
> Hi Luis,
>
> Thank you very much for your feedback!
>

Thanks to you guys for releasing Spinach!

I only had 5 failures due FakeFS (which I'm removing) and updated run
and run_feature to use "ruby" (Gem.ruby) to invoke spinach binary
(since Windows lacks shebang detection).

I couldn't resist to tweet about that last night:
https://twitter.com/#!/luislavena/status/185167883339440129/photo/1

Great work guys, pretty much everything worked :)

I'll send a pull request in the upcoming days with all my suggestions
and looking for your feedback.

I think a color blind output will be also recommended as right now
ANSI escape codes are output even when redirecting to a file (a check
for tty? and coloring could be added).

More to come, thanks again for the responses.

Reply all
Reply to author
Forward
0 new messages