From 8e506e18528546060c75bdc39c11138968786efe Mon Sep 17 00:00:00 2001 From: Andres Rey Date: Sat, 10 Dec 2016 12:09:22 +0000 Subject: Modified the expected files to match the readability.php style of result --- test/test-pages/001/expected.html | 92 +++++++++++++++++++++++++++------------ 1 file changed, 63 insertions(+), 29 deletions(-) (limited to 'test/test-pages/001') diff --git a/test/test-pages/001/expected.html b/test/test-pages/001/expected.html index fa8ffd2..bf3075c 100644 --- a/test/test-pages/001/expected.html +++ b/test/test-pages/001/expected.html @@ -1,24 +1,41 @@ -
-

So finally you're testing your frontend JavaScript code? Great! The more you +

So finally you're testing your frontend JavaScript code? Great! The more you write tests, the more confident you are with your code… but how much precisely? That's where code coverage might -help.

-

The idea behind code coverage is to record which parts of your code (functions, statements, conditionals and so on) have been executed by your test suite, to compute metrics out of these data and usually to provide tools for navigating and inspecting them.

-

Not a lot of frontend developers I know actually test their frontend code, and I can barely imagine how many of them have ever setup code coverage… Mostly because there are not many frontend-oriented tools in this area I guess.

-

Actually I've only found one which provides an adapter for Mocha and actually works…

- -

Blanket.js is an easy to install, easy to configure, +help. +

+

The idea behind code coverage is to record which parts of your code (functions, + statements, conditionals and so on) have been executed by your test suite, + to compute metrics out of these data and usually to provide tools for navigating + and inspecting them.

+

Not a lot of frontend developers I know actually test their frontend code, + and I can barely imagine how many of them have ever setup code coverage… + Mostly because there are not many frontend-oriented tools in this area + I guess.

+

Actually I've only found one which provides an adapter for Mocha and + actually works…

+ +

Blanket.js is an easy to install, easy to configure, and easy to use JavaScript code coverage library that works both in-browser and -with nodejs.

-

Its use is dead easy, adding Blanket support to your Mocha test suite is just matter of adding this simple line to your HTML test file:

<script src="vendor/blanket.js"
+with nodejs.
+                        

+

Its use is dead easy, adding Blanket support to your Mocha test suite + is just matter of adding this simple line to your HTML test file:

+
<script src="vendor/blanket.js"
         data-cover-adapter="vendor/mocha-blanket.js"></script>
 
-

Source files: blanket.js, mocha-blanket.js

-

As an example, let's reuse the silly Cow example we used in a previous episode:

// cow.js
+
+                        

Source files: blanket.js, + mocha-blanket.js +

+

As an example, let's reuse the silly Cow example we used + in a previous episode:

+
// cow.js
 (function(exports) {
   "use strict";
 
@@ -36,7 +53,9 @@ with nodejs. 

}; })(this);
-

And its test suite, powered by Mocha and Chai:

var expect = chai.expect;
+
+                        

And its test suite, powered by Mocha and Chai:

+
var expect = chai.expect;
 
 describe("Cow", function() {
   describe("constructor", function() {
@@ -59,7 +78,10 @@ describe("Cow", function() {
   });
 });
 
-

Let's create the HTML test file for it, featuring Blanket and its adapter for Mocha:

<!DOCTYPE html>
+
+                        

Let's create the HTML test file for it, featuring Blanket and its adapter + for Mocha:

+
<!DOCTYPE html>
 <html>
 <head>
   <meta charset="utf-8">
@@ -81,14 +103,26 @@ describe("Cow", function() {
 </body>
 </html>
 
-

Notes:

-
    -
  • Notice the data-cover attribute we added to the script tag loading the source of our library;
  • -
  • The HTML test file must be served over HTTP for the adapter to be loaded.
  • -
-

Running the tests now gives us something like this:

-

screenshot

-

As you can see, the report at the bottom highlights that we haven't actually tested the case where an error is raised in case a target name is missing. We've been informed of that, nothing more, nothing less. We simply know we're missing a test here. Isn't this cool? I think so!

-

Just remember that code coverage will only bring you numbers and raw information, not actual proofs that the whole of your code logic has been actually covered. If you ask me, the best inputs you can get about your code logic and implementation ever are the ones issued out of pair programming sessions and code reviews — but that's another story.

-

So is code coverage silver bullet? No. Is it useful? Definitely. Happy testing!

-
\ No newline at end of file + +

Notes:

+
  • Notice the data-cover attribute we added to the script tag + loading the source of our library;
  • +
  • The HTML test file must be served over HTTP for the adapter to + be loaded.
  • +

Running the tests now gives us something like this:

+

+ screenshot

+

As you can see, the report at the bottom highlights that we haven't actually + tested the case where an error is raised in case a target name is missing. + We've been informed of that, nothing more, nothing less. We simply know + we're missing a test here. Isn't this cool? I think so!

+

Just remember that code coverage will only bring you numbers and + raw information, not actual proofs that the whole of your code logic has + been actually covered. If you ask me, the best inputs you can get about + your code logic and implementation ever are the ones issued out of pair programming +sessions + and code reviews — + but that's another story.

+

So is code coverage silver bullet? No. Is it useful? Definitely. Happy testing! +

+
\ No newline at end of file -- cgit v1.2.3