Node: Feature request: an method for building assert tests with less code

[jy95]

Is your feature request related to a problem? Please describe.
Make similar tests without writing X times the same instructions

Describe the solution you'd like
generic function(s) could improve at least readability / maintenance. For example , using a structure like this (first draft : surely there are things that must evolue ) :

{
   // the name you want to see in console log if there is assert error(s) 
   testCaseName: 'Testing Fs constants'
   // The default assert fct that would be invoked
   defaultAssertFct: assert.strictEqual,
   // defaultMessage (hidden param) : it will be an AssertionError with default message
   // '${testCaseName} - The test N°${index} failed' , other parameters will be the same one
   tests: [
       // actual and expected are required , you can override the default message
       {actual : typeof fs.F_OK, expected: 'number', message: 'F_OK failed'},
       // possibility to change assert function (optional, default to defaultAssertFct)
       {actual : 1, expected: 2, assertFct: assert.notDeepStrictEqual},
       // ... other idea can improve this basic design
   ] 
}

Of couse, it is completely up to you to choose how you initialize the tests array following the circumstances ^^ For example , I prefer to write on the readability field :

{
  testCaseName: 'Testing Fs constants',
  defaultAssertFct: assert.strictEqual,
  tests: [fs.F_OK, fs.R_OK, fs.W_OK, fs.X_OK].map( 
     (cons) => {actual: typeof cons, expected: 'number' } 
  )
}

instead of

[fs.F_OK, fs.R_OK, fs.W_OK, fs.X_OK].forEach( 
      (cons) => assert.strictEqual(typeof cons, 'number') 
);

Describe alternatives you've considered
Copy and paste same assertion X times ^^

Notice: I would like to implement that one ^^

[BridgeAR]

I don't think that this is actually the right direction. assert should be straight forward and simple to use. What you ask for looks more like a testing framework feature instead of a assertion library feature to me.

We could add a internal helper that looks something like:

common.test(
  'Testing Fs constants', // optional
  [fs.F_OK, fs.R_OK, fs.W_OK, fs.X_OK],
  (cons) => assert.strictEqual(typeof cons, 'number')
)

It would require quite some internal magic to make this pattern work but it should be possible to return a error message that contains all necessary information.

[mscdex]

I agree, this kind of feature is best left to userland modules.

[jy95]

That is just a discussion in the "less code is better" spirit (not always true I know).

Too much duplicated code are code smell : for example if I took a test file like test-cli-eval.js : the several usage of child.exec , block scope things , almost similar kind of test done inside, etc make a hell to maintain ...

I took the example of assert because it is most speaking example 'copy & paste' ^^ ( I said it was first draft )

[Trott]

Too much duplicated code are code smell

Especially in tests, this is not necessarily so. https://stackoverflow.com/a/11837973/436641

[jy95]

DAMP and DRY are not contradictory

It seems that introducing a few DRY advantages is complex for DAMP people XD

Edit : Too bad this kind of smell-test workbook is quite rare : It would be funny to see which one(s) the contributors of Node.js would list ^^

[apapirovski]

Seems like this conversation has run its course. Going to close it out but feel free to reopen if you believe I've made a mistake. Just keeping the issue tracker tidy.