Thanks!

Sorry, but we aren't planning on open-sourcing that work in the near future because part or all of the technology may eventually return in some form.

Andrew,

Unfortunately, neither of those features are available right now, but I'll make a story for each one. Thanks for the great suggestions!

Ben

Hedge,

It's a good question. Right now, forks are double (or triple, etc) counted. That's clearly not ideal. I'll have to think about it more, but my first thought is to aggregate the stats as a group for the purpose of community metrics. I'll make a story to look into this.

Thanks!
Ben

Ryan,

Good questions.

1. We wanted to change the working directory (to the temp dir we've created) because then code like this works as expected:

within_construct |c|
c.file('foo.txt')
assert File.exist?('foo.txt')
end

But if you don't want to change the working dir (and I have several tests that don't, because of the problems you mentioned), you can pass 'false' to 'within_construct', like this:

within_construct(false) do |c|
c.file('foo.txt')
assert File.exist?(c+'foo.txt')
end

As for operations that test the full path, I'd recommend a solution like FakeFS, because Construct won't work for this scenario (it simply creates all files in a temp dir and then deletes that temp dir).

It certainly would be possible to have a different mode that writes files anywhere, but as you noted, we'd have to be really careful about not overwriting existing files, deleting files correctly, etc. I think in general, it's better to write methods that don't depend on full paths (for testability).

2. Frankly, this is only because I personally think setup/teardown methods are evil (Avdi is slowly starting to convince me it might not be so bad in a system like RSpec that has contexts, but I'm still skeptical). Of course, that's just me. I'll make a ticket to add methods like 'start' and 'stop' that would allow people to use construct in setup/teardown methods.

Awesome, glad to hear it's helpful!

Yep, we'd implemented two half-assed versions in our code, so we decided to put them together to make something whole :).

Yep, we'd implemented two half-assed versions in our code, so we decided to put them together to make something whole :).

Definitely feel free to contact me with any questions when you do the port to .NET.

Glad to hear it. After using it, please let me know if you have any problems or suggestions.

Thanks! I'm very happy to hear Devver is helping you speed up your tests. If you ever need help (or have suggestions for improving Devver), please don't hesitate to contact us at support@devver.net