100% coverage

[hueniverse]

Things are getting a bit more interesting...

It's time to add tests, verify coverage, confirm style, and automate all of this with CI. We will be using the lab module to perform all these tasks and automate it with travis.

1. Add a .travis.yml file, testing our project on node 0.10, 0.12, and io.js (latest).
2. Add a test folder with two files, version.js and index.js, each testing the corresponding file under /lib.
3. Modify the package.json file to include the tests, as well as the dev dependency to lab.
4. Add the standard hapi.js Makefile to make it easy to generate other types of reports (e.g. HTML coverage report). Note: From Assignments5 on this project only uses npm. Between assignments 4 and 5, style rules changed and the Makefile was removed from hapijs projects.
5. When using lab, enable coverage, require 100% coverage, enable linting with default rules, and use the code assertion library.
6. Write a basic test to verify our version endpoint in version.js.
7. Change the init() method to accept a port and a callback. Use the callback to return when the function completes or errors. The init() callback should return any error state as well as a reference to the newly created server. This will allow us to later stop the server when we test it.
8. Export init() and move the invocation to a new start.js file (which will call the init() function with the 8000 port and a callback the outputs the information to the console when started). Change the package.json file to use the start.js file as the starting place. This file will not be covered by tests.
9. Write a basic test to verify the init() function in index.js.
10. Bring coverage to 100% by adding more tests as needed.

Everything up to (10) should be pretty straight forward. If you are not sure on how to use lab and code, look at other hapi.js modules like hoek, qs, items, and boom (e.g. simple modules) to copy their test scripts and setup.

Getting 100% coverage can be tricky sometimes so if you are not sure, get as much coverage as you can, and comment on the lines in your pull request where you are having a hard time reaching and someone will give you a clue.

Remember to properly stop() your servers when calling the init() method in each test.

For now, avoid using any of the before() and after() lab features.

As always, ask for help and help others!

Due: 4/4

[MylesBorins]

thanks for taking the time!

[zoe-1]

Thanks for the feedback :-)

[gyaresu]

• Monkey patching parallel processing set false :ok: Thanks @zoe-1 (comment below)
• Only return err :ok:
• Using .equal(8000) in tests. :ok: (I think)
• Returning the next function: return next() :ok:
• exports.init = function (port, next) { <= That init? from index.js :question:
• Pass the path string: server.inject('/version', function(response) { :ok:
• Testing shortcuts: :ok:

var expect = Code.expect;
var describe = lab.experiment;
var it = lab.test;

[zoe-1]

@gyaresu

lab docs show how to include the parallel option.

lab.test('returns true when 1 + 1 equals 2', { parallel: false }, function (done) {
        Code.expect(1+1).to.equal(2);
        done();
 });

source: https://github.com/hapijs/lab Got the above from the documentation. Yeah, I did not include it either.

I believe monkey patching would be where we changed the default values of a plugins methods so it would break. test/index.js

    Version.register = function(server, options, next) {
        next('Plugin Error');
    };

    Version.register.attributes = {name: 'Fake Plugin'};

[tielur]

Use the testing shortcuts boilerplate used in hapi. Makes reading tests easier.

Is that just the Makefile used in the hapi project and/or the npm scripts?

[gyaresu]

@tielur I think it refers to the names you give lab and code methods. i.e.

var expect = Code.expect; 
var describe = lab.experiment; 
var it = lab.test;

[tielur]

@gyaresu ahh ok that makes sense. Thanks!

[gyaresu]

@tielur I just grabbed your code to have a look and the npm test doesn't print out the tests. Mine did that originally and I'm just looking for the advice somewhere in my PR's. (Will update when I find it but thought you'd be interested as we use different tests)

[zoe-1]

@hueniverse commented:

Some of you missed the change in the assignment to make both arguments in init() required.

I am assuming he wants the parameters in init() to be validated. Mainly, just test that a valid port was submitted.
Or, is this telling us to not create code that allows for the port to be absent?

How are we to interpret this?

[hueniverse]

The original assignment had the port as optional which meant you had to check if the first argument was a number or a function. This was removed but not everyone got the memo.

[zoe-1]

Ok. got it. I just made tests for the port again. Will go remove them.

[tielur]

@gyaresu it's the -v option that you have for lab. It does the verbose test output.

[gyaresu]

@tielur Sweet. Thanks.

[ghost]

I have a error that I cannot solve., I deleted this part :

internals.init = function () { 
     if (typeof port === 'function') { 

and changed it to :

server.connection({ port: port });

but now on every test I see a error message that port must be a string, a number. How to solve this ?

My code can be found here : https://github.com/roelof1967/hueniversity

[ghost]

@roelof1967 you have tests that are omitting the port

[ghost]

Thanks, it worked now without any problem. A new PR is submitted already

[AdriVanHoudt]

@hueniverse is it beneficial to add return before the done() calls in every test? I'm not sure if it adds readability. Although I'm personally a fan of it.

[hueniverse]

@AdriVanHoudt Nah.

[AdriVanHoudt]

@hueniverse could you go into why you choose that PR to merge? Also there is now no way for me t run the tests on my windows :neutral_face:

[simon-p-r]

You can install make on Windows, I use https://github.com/lukesampson/scoop which is very good for Windows users.

On 19 Apr 2015 10:00 am, AdriVanHoudt notifications@github.com wrote:

@hueniversehttps://github.com/hueniverse could you go into why you choose that PR to merge? Also there is now no way for me t run the tests on my windows [:neutral_face:]

— Reply to this email directly or view it on GitHubhttps://github.com/hueniverse/hueniversity/issues/79#issuecomment-94252647.

[johnmanko]

So are we creating a Makefile? Also, when you say "Add the standard hapi.js Makefile" please point to documentation on what that "standard hapi.js Makefile" is and how it should be constructed. Too many assumptions on what we know what you're talking about.

[zoe-1]

@johnmank Below is the answer to your makefile question.

As referenced in this assignments post: Note: From Assignments5 on this project only uses npm. Between assignments 4 and 5, style rules changed and the Makefile was removed from hapijs projects.