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

Service tests #937

Merged
merged 59 commits into from
Apr 28, 2017
Merged

Service tests #937

merged 59 commits into from
Apr 28, 2017

Conversation

paulmelnikow
Copy link
Member

@paulmelnikow paulmelnikow commented Apr 8, 2017

Goals

  • Eliminate manual testing which is error-prone and time consuming, and must be repeated many times through the PR review process
  • Make contributing more fun. For many, fixing bugs and making new badges is faster and more satisfying with automated tests than with manual testing.
  • Push out the work of testing new badges to a much broader net. The PR originator could write tests, but so could any other contributor who wants to push review along.
  • Detect badge failures resulting from changes in vendor contracts without waiting for user reports.
  • Detect and prevent regressions in the code.
  • Be runnable, readable, writable, and editable by as many developers as possible, including those who may not be familiar with JavaScript test tools.

For further background, I wrote a lot about my thinking in #927.

Features

  1. Perform live tests, which hit the real services.
    • Recorded tests would be valuable, especially for preventing regression, but the tooling to maintain the recorded requests (Nock Back) is buggy and needs work.
  2. Easily intercept vendor requests to test code branches which can't be exercised any other way.
  3. Manually run a subset of tests.
  4. In a pull request, show the results of the affected subset of tests.
  5. Periodically run the whole suite.
  6. Use a concise vendor spec which is easy to read, write, and modify.
  7. Help new devs along, so the process is not intimidating.
  8. Easily extended to other testing scenarios, like recorded tests, and smoke tests against the production server.

Solution

  1. Concise vendor spec, implemented as a light wrapper. Most of the work is delegated to three existing tools:
    • IcedFrisby, an API-testing tool with concise syntax which registers tests with Mocha
    • Joi, which is bundled with IcedFrisby and helps with assertions
    • Nock, an HTTP mocking and expectations library
    • icedfrisby-nock, which makes it easy to use Nock with IcedFrisby
  2. One example of a vendor test.
  3. A test runner which will run all the tests: npm run test:vendor. It's invoked during scheduled nightly builds in Travis, which means the results are public and easily accessed. Any failure will be reported as such, which seems helpful since it will bring it to our attention. However we could silence them if we find the failures are too noisy. Pushes to master run lint and the existing unit tests. Only the nightly build adds the vendor tests.
  4. A test runner that lets a contributor run just the vendors they want from the CLI: npm run test:vendor -- --only=travis
  5. A neat integration with PRs. I wanted a way to see the results of the affected vendor tests right in the PR, because it would expedite review that much more. I considered a bot that could be triggered from comments. I considered automatically detecting the affected vendors using the diff. But I settled on something much simpler, which also seems rather elegant. The contributor includes a tag like [travis], [github], or [sonar] in the PR title. The CI runner knows which PR it's building and looks up the title, extracts the tag, and runs only those vendors. If the person forgets to tag, they or the maintainer can go back and edit later. The tag is transparent, learnable, and has no new moving parts. As a bonus, it provides useful context to us humans in the PR list.
  6. Tooling to run code coverage locally, to help devs cover all the branches in the vendor they are testing. In the future, this could be reported to Coveralls during the nightly build, to make it easier for contributors to identify untested code paths, and provide a progress scorecard.
  7. Approachable developer docs which provide clear expectations for contributions.

Suggested review order

  1. Entry point: vendor/runner/cli.js
  2. Runner class: vendor/runner/runner.js
  3. Service tester class: vendor/runner/service-tester.js
  4. Vendor spec: vendor/cran.js
  5. Documentation and tutorial: vendor/README.md

Todos

@paulmelnikow
Copy link
Member Author

@niccokunzmann Since you like working on documentation, could I ask you take a look at this?

What would be really awesome is, if you could pick a service, follow the tutorial, and see how you make out!

@niccokunzmann
Copy link
Contributor

niccokunzmann commented Apr 14, 2017

I think,

  1. the tutorial should be moved to the TUTORIAL file to give it more presence and have the docs all together.
  2. the vendor readme should then link to the tutorial.

I want to create more PRs

vendor/README.md Outdated
In this tutorial, we'll write tests for the Travis badge:

```js
camp.route(/^\/travis(-ci)?\/([^\/]+\/[^\/]+)(?:\/(.+))?\.(svg|png|gif|jpg|json)$/,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this example, I would like to discuss what needs testing and what not.
This can be done with the // (1) annotations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 1002045.

vendor/README.md Outdated
.get('/rust-lang/rust.json')
.expectJSONTypes(Joi.object().keys({
name: Joi.equal('build'),
value: Joi.equal('failing', 'passing', 'unknown')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 555251d.

@niccokunzmann
Copy link
Contributor

niccokunzmann commented Apr 14, 2017

If you merge this without the travis test being implemented, the commit can be checked out and the tutorial can be continued from this. https://docs.djangoproject.com/en/dev/intro/contributing/#rolling-back-to-a-previous-revision-of-django

vendor/README.md Outdated

```js
t.create('build status on default branch')
.get('/rust-lang/rust.json')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need rust?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 5e9ec62.

vendor/README.md Outdated

When defining an IcedFrisby test, typically you would invoke the `toss()`
method, to register the test. However, this is not necessary when using
ServiceTester.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Is it implemented?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 8b14abe.

vendor/README.md Outdated
Run the test:

```
npm run test:vendor -- --only=travis
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a small "travis" above, we used thebig travis. Is this referring to /travis or the name?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this as a todo above.

vendor/README.md Outdated
```


Getting help
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be at the beginning. If I needed help during the tutorial, I would not have reached this.

@paulmelnikow
Copy link
Member Author

@niccokunzmann Just wanted to let you know I would be sitting down to incorporate your comments. Thank you. They were all super helpful! And, glad you want to create more PRs!

@niccokunzmann
Copy link
Contributor

niccokunzmann commented Apr 17, 2017

The PRs are here: paulmelnikow/shields#1 paulmelnikow/shields#2 paulmelnikow/shields#3
They go into your pull-request.

@paulmelnikow
Copy link
Member Author

Nice work! I added you as a collaborator on my fork. Feel free to push more commits to this branch if you'd like.

@paulmelnikow paulmelnikow added the developer-experience Dev tooling, test framework, and CI label Apr 17, 2017
@paulmelnikow
Copy link
Member Author

paulmelnikow commented Apr 20, 2017

Should we change the vendor-badge issue tag to service?

@paulmelnikow paulmelnikow merged commit 5c147b8 into badges:master Apr 28, 2017
@paulmelnikow
Copy link
Member Author

Merged this! Thanks @niccokunzmann and @Daniel15.

webcaetano added a commit to webcaetano/shields that referenced this pull request Apr 29, 2017
webcaetano added a commit to webcaetano/shields that referenced this pull request Apr 29, 2017
webcaetano added a commit to webcaetano/shields that referenced this pull request Apr 29, 2017
@paulmelnikow paulmelnikow deleted the vendor-tests branch June 13, 2017 14:21
paulmelnikow added a commit that referenced this pull request Oct 9, 2017
Also, include `lib/suggest.js` which is part of the server, and rename `vendor` to `service-tests` to match the renames which occurred during the review of #937.
@paulmelnikow paulmelnikow changed the title Vendor tests Service tests Dec 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer-experience Dev tooling, test framework, and CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants