स्कैला में बीडीडी - क्या इसे बदसूरत होना चाहिए?

Question

मैंने अतीत में अजगर के लिए lettuce का उपयोग किया है। यह एक साधारण बीडीडी ढांचा है जहां चश्मे बाहरी सादे पाठ फ़ाइल में लिखे जाते हैं। कार्यान्वयन प्रत्येक चरण की पहचान करने के लिए रेगेक्स का उपयोग करता है, विनिर्देशन में प्रत्येक वाक्य के लिए पुन: प्रयोज्य कोड साबित करता है।

स्केला का उपयोग करना, या तो specs2 या scalatest साथ मैं कार्यान्वयन के साथ विनिर्देश लिखने के लिए मजबूर किया जा रहा हूँ, यह एक और परीक्षण में कार्यान्वयन का पुन: उपयोग करने के लिए असंभव बना रही है (यकीन है कि, हम इसे कहीं एक समारोह में लागू हो सकता है) और बनाने विनिर्देशन से परीक्षण कार्यान्वयन को अलग करना असंभव है (कुछ ऐसा जो मैं करता था, सत्यापन के लिए ग्राहकों को स्वीकृति परीक्षण प्रदान करता था)।

निष्कर्ष निकालने पर, मैं अपना प्रश्न उठाता हूं: ग्राहकों द्वारा परीक्षण मान्य करने के महत्व को ध्यान में रखते हुए, क्या बाहरी फ़ाइल से परीक्षण लोड करने के लिए स्केल के लिए बीडीडी ढांचे में कोई तरीका है, अगर अपवाद में कोई वाक्य लागू नहीं किया गया है तो अपवाद उठाएं अभी तक और सामान्य रूप से परीक्षण निष्पादित करते हैं यदि सभी वाक्यों को लागू किया गया है?

Answer 1

मैंने अभी एक cucumber plugin for sbt खोजा है। टेस्ट/स्कैला के तहत टेस्ट लागू किए जाएंगे और विनिर्देशों को सादा txt फ़ाइलों के रूप में परीक्षण/संसाधनों में रखा जाएगा। मुझे यकीन नहीं है कि लाइब्रेरी कितनी भरोसेमंद है और अगर भविष्य में इसका समर्थन होगा।

संपादित करें: उपरोक्त प्लगइन के लिए एक रैपर है जो पूरी तरह से समस्या हल करता है और स्कैला का समर्थन करता है। https://github.com/cucumber/cucumber-jvm

Answer 2

आप अपने आप को कहा कि यह सामान्य तरीके स्काला stuf इस तरह की (तरीकों, काम करता है, लक्षण, वर्ग, प्रकार ...) के लिए प्रदान करता द्वारा कार्यान्वयन पुन: प्रयोज्य बनाने के लिए आसान है, इसलिए वहाँ वास्तव में नहीं है वहाँ एक समस्या है।

यदि आप अपने ग्राहक को कोड के बिना एक संस्करण देना चाहते हैं, तो भी आप उन्हें कोड फाइलें दे सकते हैं, और यदि वे थोड़ा वाक्यविन्यास को अनदेखा नहीं कर सकते हैं, तो संभवतः आप एक कस्टम रिपोर्टर को सभी टेक्स्ट लिखने के लिए लिख सकते हैं एक फ़ाइल, शायद एचटीएमएल या कुछ के रूप में भी स्वरूपित।

एक और विकल्प JBehave या किसी अन्य JVM आधारित ढांचे का उपयोग करना होगा, उन्हें किसी समस्या के बिना स्कैला के साथ काम करना चाहिए।

Answer 3

यह सब व्यापार-बंद के बारे में है। विनिर्देशों की ककड़ी शैली बहुत अच्छी है क्योंकि यह शुद्ध पाठ है, जो आसानी से संपादन योग्य और गैर-कोडर द्वारा पठनीय है।

हालांकि वे विनिर्देशों के रूप में भी बहुत कठोर हैं क्योंकि वे सुविधाओं और Given-When-Then के आधार पर एक सख्त प्रारूप लगाते हैं। Specs2 for example में हम जो भी पाठ चाहते हैं उसे लिख सकते हैं और केवल उन पंक्तियों को एनोटेट कर सकते हैं जो सिस्टम या सत्यापन पर कार्रवाई के लिए हैं। दोष यह है कि टेक्स्ट एनोटेटेड हो गया है और pending स्पष्ट रूप से निर्दिष्ट किया जाना चाहिए कि यह अभी तक लागू नहीं किया गया है। इसके अलावा एनोटेशन केवल कुछ कोडों का संदर्भ है, कहीं कहीं रहना, और आप निश्चित रूप से पुन: प्रयोज्यता प्राप्त करने के लिए सामान्य प्रोग्रामिंग तकनीकों का उपयोग कर सकते हैं।

Btw, link above व्यापार बंद का एक दिलचस्प उदाहरण है: इस फाइल में, पहले कल्पना "भद्दा" है, लेकिन अधिक संकलन समय जांच करता है कि When कदम एक Given कदम या कि हम से जानकारी का उपयोग करता हैं Then -> When चरणों का अनुक्रम नहीं है। दूसरा विनिर्देश अच्छा है लेकिन अधिक त्रुटि-प्रवण भी है।

फिर नियमित अभिव्यक्तियों को बनाए रखने का मुद्दा है। यदि सुविधाओं और लोगों को लागू करने वाले लोगों के बीच सख्त अलगाव है, तो कार्यान्वयन तोड़ना बहुत आसान है, भले ही कुछ भी महत्वपूर्ण परिवर्तन न हो।

अंत में, संस्करण नियंत्रण का सवाल है। दस्तावेज़ का मालिक कौन है? हम कैसे सुनिश्चित कर सकते हैं कि कोड spec के साथ सिंक हो रहा है? आवश्यकता होने पर विनिर्देशन कौन करता है?

अब तक, सही समाधान नहीं है। मेरा स्वयं का निष्कर्ष यह है कि बीडीडी कलाकृतियों को डेवलपर्स के हाथ में होना चाहिए और अन्य हितधारकों द्वारा सत्यापित किया जाना चाहिए, अगर कोड पठनीय या एचटीएमएल/पीडीएफ आउटपुट पढ़ रहा हो तो सीधे कोड पढ़ना चाहिए। और यदि बीडीडी कलाकृतियों के डेवलपर्स के स्वामित्व में हैं तो वे अपने जीवन को सत्यापन के साथ अपने जीवन को आसान बनाने के लिए भी उपयोग कर सकते हैं (जब संभव हो तो एक कंपाइलर का उपयोग करके) और रखरखाव (स्वचालित रिफैक्टरिंग का उपयोग करके)।

Answer 4

एरिक का मुख्य डिजाइन मानदंड निष्पादन योग्य विनिर्देश विकास (रिफैक्टरिंग के माध्यम से) की स्थिरता था और सरल पाठ की "सुंदरता" के कारण प्रारंभिक सुविधा नहीं थी।

http://etorreborre.github.io/specs2/

specs2 की सुविधाओं को देखने के कर रहे हैं: डिफ़ॉल्ट रूप से उदाहरण के

1. समवर्ती निष्पादन
2. ScalaCheck गुण
3. Mockito साथ Mocks
4. डाटा टेबल
5. AutoExamples, जहां उदाहरण कोडका वर्णन करने के लिए स्रोत कोड निकाला गया है
6. बना सकते हैं और रचना
7. चाहिए साथ उपयोग किए जाने योग्य और चाहिए
8. रिटर्निंग (उदाहरण के लिए JUnit परीक्षण में)
9. specs2 की पुन: प्रयोज्य बाहर "कार्यात्मक" परिणाम या फेंक अपवादों के
10. आसान matchers के एक अमीर पुस्तकालय
Fitnesse की तरह विनिर्देशों (Markdown मार्कअप के साथ)
11. एचटीएमएल रिपोर्टिंग लेखन स्वीकृति परीक्षण के लिए दस्तावेज़ बनाने के लिए, एक उपयोगकर्ता गाइड
बनाने के लिए
12. प्रपत्र साथ एपीआई का दस्तावेजीकरण के लिएस्निपेट्स हमेशा अप करने की तारीख कोड
13. एकता एसबीटी और JUnit उपकरण (Maven, IDEs, ...)

Specs2 दोनों डिजाइन और कार्यान्वयन में काफी प्रभावशाली है के साथ। यदि आप बारीकी से देखते हैं तो आप देखेंगे कि डीएसएल को बढ़ाया जा सकता है जबकि आप टाइपएफ़-टाई और विकास के तहत डोमेन कोड के मजबूत कमांड को रखते हैं।

वह जो "अधिक बदसूरत" तर्क को छोड़ देता है और इसे गंभीरता से प्रयास करता है वह शक्ति पायेगा। संरचित रूपों और स्निपेट्स को चेकआउट करें