Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document that each test block returns to the original cwd? #100

Open
schwern opened this issue Apr 8, 2014 · 4 comments
Open

Document that each test block returns to the original cwd? #100

schwern opened this issue Apr 8, 2014 · 4 comments

Comments

@schwern
Copy link
Contributor

schwern commented Apr 8, 2014

I experimentally confirmed that tests blocks will return you to the original cwd the test was started in. This is a very useful feature, but I couldn't find it documented in either Fennec or Test::WorkFlow.

I'm hesitant to just document it as it appears to be a side effect of forking, and setting FENNEC_PARALLEL=0 breaks it. I use that when I want to debug tests.

Here's a small test to demonstrate the feature.

use Fennec;
use Path::Tiny;

tests "chdir" => sub {
    note( Path::Tiny->cwd );
    ok chdir "/";
};

tests "cwd" => sub {
    note( Path::Tiny->cwd );
    ok chdir "/";
};

done_testing;
@exodist
Copy link
Owner

exodist commented Apr 8, 2014

It is indeed a side-effect, but It can also be a useful feature. I would be
in support of making it a spec'd behavior of test blocks, but we need to
make them do it when parallel is turned off as well. I don't have time to
implement this ATM.

-Chad

P.S.

Whats your overall opinion of Fennec? Have you used these features yet:
tests foo => (
todo => "This block is todo", # Can use skip => '...' as well
code => sub { ... },
);

In Fennec::Declare this would be:
tests foo(todo => 'this block is todo') { ... }

On Tue, Apr 8, 2014 at 1:55 PM, Michael G. Schwern <notifications@github.com

wrote:

I experimentally confirmed that tests blocks will return you to the
original cwd the test was started in. This is a very useful feature, but I
couldn't find it documented in either Fennec or Test::WorkFlow.

I'm hesitant to just document it as it appears to be a side effect of
forking, and setting FENNEC_PARALLEL=0 breaks it. I use that when I want
to debug tests.

Here's a small test to demonstrate the feature.

use Fennec;
use Path::Tiny;

tests "chdir" => sub {
note( Path::Tiny->cwd );
ok chdir "/";
};

tests "cwd" => sub {
note( Path::Tiny->cwd );
ok chdir "/";
};

done_testing;

Reply to this email directly or view it on GitHubhttps://github.com//issues/100
.

@schwern
Copy link
Contributor Author

schwern commented Apr 9, 2014

I appreciate you don't have time to do it right now. On the off chance I need to shave this yak, would the chdir $original_dir go in Test::Workflow or Fennec?

I've only used tests $name => sub { ... } so far. It works, and it's nicer than the note $name; { ... } style I'd been using before with plain Test::More. I haven't had need yet for more features. I'm still in greenfield development.

The main downside I've encountered is the aforementioned forking makes using the debugger difficult. I have to turn it off when running a test with the debugger which can change how the test behaves.

@exodist
Copy link
Owner

exodist commented Apr 9, 2014

You can try running with parallel => 1, whuch will still fork, but only one
proc will run at a time. You can also use the FENNEC_TEST env var (that
might not be the right name) when given a test name it will only run that
yest. When given a line number it only runs the test that crosses that line.

As for the chdir, that should be a fennec feature, not a test::workflow
feature. Just like parallel is not part of test::workflow.
On Apr 8, 2014 6:02 PM, "Michael G. Schwern" notifications@github.com
wrote:

I appreciate you don't have time to do it right now. On the off chance I
need to shave this yak, would the chdir $original_dir go in
Test::Workflow or Fennec?

I've only used tests $name => sub { ... } so far. It works, and it's
nicer than the note $name; { ... } style I'd been using before with plain
Test::More. I haven't had need yet for more features. I'm still in
greenfield development.

The main downside I've encountered is the aforementioned forking makes
using the debugger difficult. I have to turn it off when running a test
with the debugger which can change how the test behaves.

Reply to this email directly or view it on GitHubhttps://github.com//issues/100#issuecomment-39919192
.

@jkeroes
Copy link

jkeroes commented Apr 9, 2014

I've been using FENNEC_PARALLEL=0 and parallel => 0 with perl -d.

Make sure you have Fennec 2.014+ if you want to use the env var.

On Tue, Apr 8, 2014 at 6:06 PM, Chad Granum notifications@github.comwrote:

You can try running with parallel => 1, whuch will still fork, but only one
proc will run at a time. You can also use the FENNEC_TEST env var (that
might not be the right name) when given a test name it will only run that
yest. When given a line number it only runs the test that crosses that
line.

As for the chdir, that should be a fennec feature, not a test::workflow
feature. Just like parallel is not part of test::workflow.
On Apr 8, 2014 6:02 PM, "Michael G. Schwern" notifications@github.com
wrote:

I appreciate you don't have time to do it right now. On the off chance I
need to shave this yak, would the chdir $original_dir go in
Test::Workflow or Fennec?

I've only used tests $name => sub { ... } so far. It works, and it's
nicer than the note $name; { ... } style I'd been using before with plain
Test::More. I haven't had need yet for more features. I'm still in
greenfield development.

The main downside I've encountered is the aforementioned forking makes
using the debugger difficult. I have to turn it off when running a test
with the debugger which can change how the test behaves.

Reply to this email directly or view it on GitHub<
https://github.com/exodist/Fennec/issues/100#issuecomment-39919192>

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/100#issuecomment-39919372
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants