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

Add more tests #29

Closed
SamVerschueren opened this issue Jun 3, 2016 · 11 comments · Fixed by #689
Closed

Add more tests #29

SamVerschueren opened this issue Jun 3, 2016 · 11 comments · Fixed by #689
Labels
🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted

Comments

@SamVerschueren
Copy link
Collaborator

SamVerschueren commented Jun 3, 2016

Issuehunt badges

I want to write more tests but testing this library is a little bit tricky. I see two options here.

  1. Mock the execa calls
  2. Checkout sindre-playground and run np

The first one doesn't really feel quite ok. Option number 2 looks much better but will create a lot of releases and noise.

Any other suggestions for adding more tests?


IssueHunt Summary

tommy-mitchell tommy-mitchell has been rewarded.

Backers (Total: $80.00)

Submitted pull Requests


Tips

@Hypercubed
Copy link
Contributor

As I mentioned in #36 probably need a mock project, otherwise, you will always get a "Not on master branch" or such error. You could use sindre-playground but only three people could run tests unless you know a way to mock the registry.

@Hypercubed
Copy link
Contributor

Hypercubed commented Jun 16, 2016

Here is one way to do this tests... assuming you have a clean mock project at ./playground:

(note sindre-playground won't work, it doesn't have any tests).

import test from 'ava';
import execa from 'execa';

test.before(() => {
    process.chdir('./playground');
    process.env.DEBUG = 'np';
});

test('defaults', t => {
    return execa('../cli.js', ['--dry']).then(result => {
        t.regex(result.stderr, /del node_modules/);
        t.regex(result.stderr, /npm \[ 'install' \]/);
        t.regex(result.stderr, /npm \[ 'test' \]/);
        t.regex(result.stderr, /npm \[ 'version', 'patch' \]/);
        t.regex(result.stderr, /git \[ 'push', '--follow-tags' \]/);
    });
});

test('yolo', t => {
    return execa('../cli.js', ['--dry', '--yolo']).then(result => {
        t.falsy(/del node_modules/.test(result.stderr));
        t.falsy(/npm \[ 'install' \]/.test(result.stderr));
        t.falsy(/npm \[ 'test' \]/.test(result.stderr));
        t.regex(result.stderr, /npm \[ 'version', 'patch' \]/);
        t.regex(result.stderr, /git \[ 'push', '--follow-tags' \]/);
    });
});

@Hypercubed
Copy link
Contributor

@Hypercubed
Copy link
Contributor

Might be easier to mock execa?!

@jamestalmage
Copy link
Contributor

I think we should start by exposing the tasks functions, and testing them individually.

For all the git stuff, you can just clone from one directory to another (origin does not have to be a remote server, it can also be path on your file system).

When it comes to the Travis and AppVeyor stuff, maybe people just need to fork sindre-playground, set up Travis and AppVeyor for their forks, and provide their own credentials for pushing to GitHub for their forks (./tests/config.json - ignored in .gitignore). We would need to create a contributing.md to explain all that. Those tests probably should just skip if users don't setup that config file.

For actually publishing to npm, I am tempted to say just mock execa for that. Although, maybe we could look into one of the sinopia forks (though none seem to be really active).

@sindresorhus
Copy link
Owner

@jamestalmage Agreed.

When it comes to the Travis and AppVeyor stuff, maybe people just need to fork sindre-playground, set up Travis and AppVeyor for their forks

I can just add anyone that wants to work on it.

For actually publishing to npm, I am tempted to say just mock execa for that

Mocking is enough. We don't need to publish as that's already tested by npm.

@IssueHuntBot
Copy link

@issuehuntfest has funded $80.00 to this issue. See it on IssueHunt

@itaisteinherz
Copy link
Collaborator

itaisteinherz commented Apr 5, 2019

@sindresorhus I created #381, #383 and #384 (see #354 (comment)). I tried to avoid creating issues that have a scope that is too wide, but if you think we should change something feel free to update the issues (#383 may be a bit too big as it requires many (small) tests). As those get resolved we can create more tests issues, depending on how things go.

@issuehunt-oss issuehunt-oss bot added the 💵 Funded on Issuehunt This issue has been funded on Issuehunt label May 10, 2019
@chinesedfan
Copy link
Collaborator

@sindresorhus Would you mind setting up coverage report? Like codecov.io or coveralls.

@sindresorhus
Copy link
Owner

We can add nyc locally, but I don't see much value yet in codecov.io as the kinda tests we need, integration tests, will not affect code coverage much.

@issuehunt-oss
Copy link

issuehunt-oss bot commented Sep 2, 2023

@sindresorhus has rewarded $72.00 to @tommy-mitchell. See it on IssueHunt

  • 💰 Total deposit: $80.00
  • 🎉 Repository reward(0%): $0.00
  • 🔧 Service fee(10%): $8.00

@issuehunt-oss issuehunt-oss bot added 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt and removed 💵 Funded on Issuehunt This issue has been funded on Issuehunt labels Sep 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants