timer-set - npm Package Compare versions

Comparing version 1.0.1 to 1.0.2

examples/col-group/main-col-group.js

@@ -38,3 +38,3 @@ /***************************************************************************************************
 const TimerSet = require('../../lib/timer-set'); //NB To use trapit as npm module: require('timer-set');
-const [INPUT_FILE, 													   DELIM, COL] = 
+const [INPUT_FILE, 													                           DELIM, COL] = 
       ['./examples/col-group/fantasy_premier_league_player_stats.csv', ',',   6];
@@ -41,0 +41,0 @@

package.json

 {
   "name": "timer-set",
-  "version": "1.0.1",
+  "version": "1.0.2",
   "description": "Code timing class",
@@ -5,0 +5,0 @@ "homepage": "https://github.com/BrenPatF/timer-set_nodejs#readme",

README.md

@@ -101,3 +101,3 @@ # timer-set
 
-This kind of package would usually be thought hard to unit-test, with CPU and elapsed times being inherently non-deterministic. However, this is a good example of the power of the design pattern that I recently introduced: One of the inputs is a yes/no flag indicating whether to mock the system timing calls, or not. The function calls used to return epochal CPU and elapsed times are actually parameters that take the (Windows) system functions as defaults, while in the mocked case deterministic versions are supplied by the test driver, that read the values to return from the input scenario data. In this way we can test correctness of the timing aggregations, independence of timer sets etc. using the deterministics functions; on the other hand, one of the key benefits of automated unit testing is to test the actual dependencies, and we do this in the non-mocked case by passing in 'sleep' times to the wrapper function and testing the outputs against ranges of values.
+This kind of package would usually be thought hard to unit-test, with CPU and elapsed times being inherently non-deterministic. However, this is a good example of the power of the design pattern that I recently introduced: One of the inputs is a yes/no flag indicating whether to mock the system timing calls, or not. The function calls used to return epochal CPU and elapsed times are actually parameters that take the (Windows) system functions as defaults, while in the mocked case deterministic versions are supplied by the test driver, that read the values to return from the input scenario data. In this way we can test correctness of the timing aggregations, independence of timer sets etc. using the deterministic functions; on the other hand, one of the key benefits of automated unit testing is to test the actual dependencies, and we do this in the non-mocked case by passing in 'sleep' times to the wrapper function and testing the outputs against ranges of values.
 
@@ -104,0 +104,0 @@ ## See also

No alert changes

Improved metrics

Total package byte prevSize

2461770

No dependency changes