2013-01-17 13 views
36

हास्केल में फ़ंक्शन दृश्यता और इकाई परीक्षण से आप कैसे निपटते हैं?फ़ंक्शन गोपनीयता और इकाई परीक्षण Haskell

यदि आप मॉड्यूल में प्रत्येक फ़ंक्शन को निर्यात करते हैं ताकि यूनिट परीक्षणों तक पहुंच हो, तो आप अन्य लोगों को उन कार्यों को कॉल करने का जोखिम देते हैं जो सार्वजनिक API में नहीं होनी चाहिए।

मैं एक #ifdef साथ {-# LANGUAGE CPP #-} का उपयोग कर और उसके बाद निर्यात आसपास के बारे में सोचा:

{-# LANGUAGE CPP #-} 

module SomeModule 
#ifndef TESTING 
(export1 
, export2 
) 
#endif 
where 

वहाँ एक बेहतर तरीका है?

+0

https://stackoverflow.com/questions/34571/how-do-i-test-a-class-that-has-private-methods-fields-or-inner-classes – Raedwald

उत्तर

55

सामान्य सम्मेलन

module SomeModule.Internal where 

-- ... exports all private methods 

और उसके बाद सार्वजनिक एपीआई यानी सार्वजनिक और निजी भागों में अपने मॉड्यूल विभाजित करने के लिए,

module SomeModule where (export1, export2) 

import SomeModule.Internal 

तो फिर तुम परीक्षण और अन्य स्थानों पर जहां में SomeModule.Internal आयात कर सकते हैं अपने आंतरिक कार्यान्वयन तक पहुंच प्राप्त करने के लिए महत्वपूर्ण है।

विचार है कि अपने पुस्तकालय कभी नहीं गलती से कॉल निजी एपीआई के उपयोगकर्ताओं, पर वे उपयोग कर सकते हैं, तो जानते हैं कि वे क्या कर रहे हैं (डिबगिंग आदि) है। जबरन निजी एपीआई छिपाने की तुलना में यह आपके पुस्तकालय की उपयोगिता को बहुत बढ़ा देता है।

+1

का संभावित डुप्लिकेट यह इनलाइनिंग को प्रभावित करेगा (संकलन समय अनुकूलन)? Https://www.haskell.org/haskellwiki/Performance/GHC# पढ़ना ऐसा लगता है जैसे ऐसा होगा ... तो आप या तो इकाई परीक्षण लिख सकते हैं या अनुकूलित कर सकते हैं? (कृपया, कोई मुझे बताता है कि मैं गलत हूं!) – tlo

+0

यदि चिंता यह है कि इन तकनीक द्वारा इनलाइन-एक बार ऑप्टिमाइज़ेशन अक्षम कर दिया जाएगा, तो ध्यान दें कि आप यह सुनिश्चित करने के लिए स्पष्ट रूप से स्पष्ट इनलाइनिंग का उपयोग कर सकते हैं कि ऐसा होता है। – Jules

+0

किसी भी व्यक्ति के लिए 'SomeModule.Internal' मॉड्यूल बनाने के लिए, Haskell-Stack के साथ इस सलाह का उपयोग करने का प्रयास करने के लिए, आपको एक उपयुक्त निर्देशिका संरचना बनाने की आवश्यकता है - यह [देखें] [https://stackoverflow.com/questions/28193295/ लोड एक मॉड्यूल में GHCi-दर-मॉड्यूल-नाम-जब मॉड्यूल-नाम-does not के मैचों-फ़ाइल-नाम)। संदर्भ के लिए – hnefatl

7

परीक्षण के लिए आप सामान्य रूप से cabal प्रोजेक्ट फ़ाइल में, लाइब्रेरी के बीच, उत्पादन निष्पादन योग्य, और test-suite निष्पादन योग्य है जो पुस्तकालय कार्यों का परीक्षण करता है, इसलिए परीक्षण दावा कार्यों को अलग रखा जाता है।

बाहरी फ़ंक्शन दृश्यता के लिए आप "खुला-मॉड्यूल" अनुभाग और "अन्य-मॉड्यूल" अनुभाग के बीच लाइब्रेरी मॉड्यूल को विभाजित करते हैं।

+0

यहां निष्पादन योग्य के लिए एक कैबल पैकेज का एक उदाहरण है, जो लाइब्रेरी में विभाजित है और निष्पादन योग्य है: http://www.haskell.org/cabal/users-guide/developing-packages.html#configurations –

+0

परीक्षण कर सकते हैं 'अन्य मॉड्यूल' अनुभाग में मॉड्यूल के खिलाफ परीक्षण शामिल हैं? यूनिट परीक्षण आंतरिक बाहरी ग्राहकों को उजागर किए बिना आंतरिक मुझे बहुत वांछनीय लगता है। – Blaisorblade

+1

@Blaisorblade हां, 'अन्य मॉड्यूल' से मॉड्यूल तक पहुंचने के लिए टेस्ट-सूट का तरीका कैबल फ़ाइल 'एचएस-स्रोत-डीआईआरएस: src, test' परीक्षण सूट के लिए निर्दिष्ट है। दूसरे शब्दों में 'src' भी परीक्षण सूट में संकलित किया गया है। नकारात्मकता यह है कि फिर आप अपने स्रोत को दो बार संकलित करते हैं: सामान्य तरीका, और फिर परीक्षणों के लिए। लेकिन यह मुझे सबसे अच्छा तरीका पता है। –

संबंधित मुद्दे