"यूनिट परीक्षण" एक रिपोर्ट

Question

क्रिस्टल रिपोर्ट्स या SQL सर्वर रिपोर्टिंग सेवाओं जैसे कुछ रिपोर्ट इंजन द्वारा बनाई गई रिपोर्ट "इकाई परीक्षण" कैसे होगी?

Answer 1

रिपोर्ट के साथ समस्या GUI के साथ समस्या के समान है। यदि रिपोर्ट/जीयूआई में बहुत सारी (गलत जगह) खुफिया जानकारी है तो यह परीक्षण को कठिन बनायेगा। सामग्री (डेटा का उपयोग/डोमेन/व्यापार के नियम) से अलग प्रस्तुति: समाधान तो

• Separated Presentation है। वर्तमान संदर्भ में, आप कुछ प्रकार के व्यूमोडेल क्लास बनाते हैं जो अंतिम रिपोर्ट की सामग्री को प्रतिबिंबित करता है (उदाहरण के लिए यदि आपके पास ऑर्डर विवरण और आपकी रिपोर्ट में लाइन आइटम हैं, तो इस श्रेणी में विवरण और लाइन की एक सूची होनी चाहिए वस्तु वस्तुओं)। ViewModel परीक्षण करने के लिए असीम रूप से सरल है। अंतिम-मील, सामग्री को प्रस्तुति लागू करना अपेक्षाकृत मामूली (पतला यूआई) होना चाहिए।
  उदा। यदि आप अपनी रिपोर्ट प्रस्तुत करने के लिए xslt का उपयोग करते हैं, तो आप XmlUnit या स्ट्रिंग तुलना जैसे टूल का उपयोग कर डेटा एक्सएमएल का परीक्षण कर सकते हैं। आप अंतिम रिपोर्ट के लिए डेटा एक्सएमएल पर एक्सएसएल ट्रांसफॉर्मेशन में उचित आत्मविश्वास कर सकते हैं ... इसके अलावा यहां कोई भी बग ठीक करने के लिए तुच्छ होगी।
• हालांकि यदि आप क्रिस्टल रिपोर्ट्स जैसे तृतीय पक्ष विक्रेताओं का उपयोग कर रहे हैं, तो आपके पास रिपोर्ट पीढ़ी में हुक करने के लिए कोई नियंत्रण/पहुंच नहीं है।ऐसे मामलों में, आप जो कर सकते हैं वह सबसे अच्छा है जो गोल्डन फाइल्स नामक प्रतिनिधि/अपेक्षित आउटपुट फाइल (उदा। पीडीएफ) उत्पन्न करता है। वास्तविक आउटपुट की तुलना करने के लिए अपने परीक्षणों में इसे केवल पढ़ने के लिए संसाधन के रूप में उपयोग करें। हालांकि यह दृष्टिकोण बहुत नाजुक है .. इसमें रिपोर्ट जनरेशन कोड में कोई भी महत्वपूर्ण परिवर्तन पिछले सभी गोल्डन फ़ाइलों को गलत प्रस्तुत कर सकता है। तो उन्हें पुनर्जन्म लेना होगा। यदि स्वचालन के अनुपात का लाभ उठाने की लागत बहुत अधिक है, तो मैं पुराने स्कूल शब्द दस्तावेज़ परीक्षण योजनाओं के साथ मैनुअल कहूंगा।

Answer 2

सबसे अच्छा मैं सोच सकता हूं, परिणाम अपेक्षित आउटपुट की तुलना कर रहा है।

शायद कुछ खुफिया जोड़ा जा सकता है, लेकिन इन बड़े ब्लॉक का परीक्षण करना इतना आसान नहीं है।

Answer 3

मैं गेमकैट से सहमत हूं।

रिपोर्ट को निश्चित (स्थिर) डेटा से उत्पन्न करें, और उस डेटा के अपेक्षित आउटपुट से इसकी तुलना करें।

उसके बाद आप इस तरह के अंतर के रूप में सरल परीक्षण का उपयोग करने के (पता चल सके कि फ़ाइलें एक जैसे हैं)

Answer 4

हमारे अपने जावा आधारित रिपोर्टिंग उत्पाद, i-net Clear Reports के परीक्षण के लिए सक्षम हो सकता है, हम एक बार परीक्षण की रिपोर्ट की एक पूरी धसान चलाने , उन्हें विभिन्न निर्यात प्रारूपों में निर्यात करना, सुनिश्चित करें कि आउटपुट वांछित है, और उसके बाद लगातार इन समान रिपोर्टों को दैनिक डेटा पर तुलना करके, दैनिक डेटा चलाते हैं। तब कोई अंतर भिन्न परीक्षण विफलताओं के रूप में दिखाई देता है।

यह हमारे लिए बहुत अच्छा काम करता है। इसका नुकसान कोई मामूली मतभेद है जो टेस्ट डेटा रीसेट होने तक परीक्षण विफलताओं के रूप में कोई फर्क नहीं पड़ता है।

साइड नोट: यह बिल्कुल एक यूनिट परीक्षण नहीं बल्कि स्वीकृति परीक्षण है। लेकिन मुझे नहीं लगता कि आप वास्तव में एक संपूर्ण रिपोर्ट "इकाई परीक्षण" कैसे कर सकते हैं। एक UI का परीक्षण, विनम्र देखें तरह के लिए कुछ विचार का उपयोग कर परीक्षण सक्षम करने के लिए संरचना की रिपोर्ट:

Answer 5

मेरे वर्तमान विचार दो स्तरों पर परीक्षण बनाने के लिए है:

• ईकाई परीक्षण। रिपोर्ट खुद को जितना संभव हो गूंगा के रूप में बनाया जाएगा। इसमें ज्यादातर साधारण क्षेत्र बाइंडिंग शामिल होनी चाहिए। डेटा बाइंडिंग/ऑब्जेक्ट्स जो इन बाइंडिंग्स के स्रोत के रूप में कार्य करती हैं, तब इकाई परीक्षण की जा सकती हैं।

• स्वीकृति परीक्षण: कुछ उदाहरण रिपोर्ट जेनरेट करें। पहले हाथ से उन्हें सत्यापित करें। फिर एक स्वचालित परीक्षण सेटअप करें जो diff का उपयोग करके तुलना करता है।