AFAIK, यूनिट परीक्षण कार्यात्मक परीक्षण नहीं है। एक छोटे से उदाहरण से समझाता हूं। आप परीक्षण करना चाहते हैं कि क्या ईमेल वेब ऐप की लॉगिन कार्यक्षमता काम कर रही है या नहीं, जैसा कि एक उपयोगकर्ता करेगा। उसके लिए, आपके कार्यात्मक परीक्षण इस तरह होने चाहिए।
1- existing email, wrong password -> login page should show error "wrong password"!
2- non-existing email, any password -> login page should show error "no such email".
3- existing email, right password -> user should be taken to his inbox page.
4- no @symbol in email, right password -> login page should say "errors in form, please fix them!"
क्या हमारे कार्यात्मक परीक्षणों की जाँच करनी चाहिए कि क्या हम अमान्य इनपुटों के साथ लॉगिन कर सकते हैं? उदाहरण के लिए। ईमेल में कोई @ प्रतीक नहीं है, उपयोगकर्ता नाम में एक से अधिक डॉट (केवल एक डॉट की अनुमति है), .com @ से पहले प्रकट होता है आदि? आम तौर पर, नहीं! उस तरह का परीक्षण आपकी इकाई परीक्षणों में जाता है।
आप जाँच सकते हैं कि क्या अवैध इनपुट यूनिट परीक्षणों के अंदर अस्वीकार कर दिए गए हैं जैसा कि नीचे दिए गए परीक्षणों में दिखाया गया है।
class LoginInputsValidator
method validate_inputs_values(email, password)
1-If email is not like string.string@myapp.com, then throw error.
2-If email contains abusive words, then throw error.
3-If password is less than 10 chars, throw error.
ध्यान दें कि कार्यात्मक परीक्षण 4 वास्तव में इकाई परीक्षण 1 क्या कर रहा है। कभी-कभी, कार्यात्मक परीक्षण विभिन्न कारणों से यूनिट परीक्षणों द्वारा किए गए परीक्षण के कुछ (सभी नहीं) को दोहरा सकते हैं। हमारे उदाहरण में, हम यह जांचने के लिए कार्यात्मक परीक्षण 4 का उपयोग करते हैं कि क्या कोई विशेष त्रुटि संदेश अमान्य इनपुट दर्ज करने पर दिखाई देता है । हम परीक्षण करना चाहते हैं कि क्या सभी खराब इनपुट खारिज हो गए हैं या नहीं। यह इकाई परीक्षणों का काम है।
