तो मेरा कोड यह है:

const handler = (event = { body: {} }) => {
  if (isEventEmpty(event)) {
    return Promise.resolve({})
  }
  const getPayload = R.compose(
    R.flatten,
    R.map(x => transformRecord(x)),
    R.pluck('Stuff'),
    R.path(['body'])
  )
  const processEvent = R.compose(
    toPromise,
    R.ifElse(isEventEmpty, R.always({}), getPayload)
  )
  return processEvent(event)
}

module.exports = { handler }

if (isEventEmpty(event)) { के साथ कवरेज 66.67% है जो ठीक है। लेकिन इसके बिना if कवरेज 0 होगा। ध्यान दें कि मैं R.ifElse रामदा से कंपोजेबल का उपयोग करता हूं। सभी यूनिट परीक्षण पास हो जाते हैं इसलिए मैं उन्हें नहीं दिखा रहा हूं, लेकिन कवरेज रिपोर्ट 0% Branches 0/1 दिखाती है। अनिवार्य if शाखा के साथ मेरे पास कवरेज रिपोर्ट में 2/3 है।

क्या किसी को भी अपना कोड लिखते समय if-else ब्रांचिंग (या लूप) का उपयोग नहीं करने का अनुभव है? ऐसा लगता है कि nyc केवल if-else में देख रहा है, शाखाओं के लिए/जबकि मैं गलत हो सकता हूं।

0
mjakic 1 जुलाई 2019, 12:51

1 उत्तर

सबसे बढ़िया उत्तर

मुझे नहीं लगता कि कोड कवरेज काम नहीं कर रहा है, यह केवल एक कार्यात्मक प्रोग्रामिंग सेटिंग में कम उपयोगी होता जा रहा है।

काम पर एक प्रस्तुति में मैंने यही साझा किया है:

दिया गया yes-no.js:

module.exports = bool => bool === true ? 'yes' : 'no';

और yes-no-fp.js

const {ifElse, equals, always} = require('ramda');

module.exports = ifElse(equals(true),always('yes'),always('no'));

और निम्नलिखित परीक्षण:

test.true(yesOrNo(true) === 'yes');
test.true(yesOrNoFp(true) === 'yes');

फिर आपको निम्न कोड कवरेज मिलता है:

enter image description here

जैसा कि आप उसी परीक्षण के लिए देख सकते हैं:

  1. कार्यात्मक प्रोग्रामिंग संस्करण 100% शाखा कवरेज की रिपोर्ट करता है
  2. "अनिवार्य" संस्करण 50% शाखा कवरेज की रिपोर्ट करता है

व्यक्तिगत रूप से मुझे लगता है कि यह एक अच्छी बात है क्योंकि मैं हमेशा अपनी टीम के साथियों से यह कहता हूं: कोड कवरेज एक उपकरण है नियम नहीं। इससे आपको कम लेकिन बेहतर परीक्षण तैयार करने में मदद मिलेगी। यह कभी लक्ष्य नहीं होना चाहिए।

यदि 100% कोड कवरेज आपका उद्देश्य है तो एक मौका है कि कोड समीक्षा में कोई भी यह नहीं बताएगा कि आप एक टेस्ट केस खो रहे हैं। यदि आपने पूरे कोड को सफलतापूर्वक कवर कर लिया है तो उन्हें क्यों करना चाहिए?


तो आप बेहतर परीक्षण कैसे लिखते हैं?

मुझे यकीन नहीं है कि उस प्रश्न का एक ही उत्तर है, लेकिन मैं निश्चित रूप से अनुशंसा करता हूं कि आप संपत्ति-आधारित परीक्षण देखें। यह निश्चित रूप से अधिक गहन परीक्षण लिखने में आपकी सहायता कर सकता है।

यदि आप रुचि रखते हैं तो मुझे यह लेख अत्यंत उपयोगी लगा।

4
customcommander 1 जुलाई 2019, 13:13