क्या मुझे ऐसे मामलों का परीक्षण करना चाहिए जिनमें

Question

Sample स्थिति S या P स्थिति को हटाया जा सकता है। मेरे पास ये परीक्षण हैं:

@Test 
public void canBeDeletedWhenStatusIsP() { 
    Sample sample = new Sample(); 
    sample.setState("P"); 
    assertTrue(sample.canBeDeleted()); 
} 

@Test 
public void canBeDeletedWhenStatusIsS() { 
    Sample sample = new Sample(); 
    sample.setState("S"); 
    assertTrue(sample.canBeDeleted()); 
} 

क्या मुझे आगे जाना चाहिए? मुझे परीक्षण कैसे करना चाहिए जब नमूना हटाया नहीं जा सकता है? उदाहरण के लिए:

@Test 
public void cantBeDeletedWhenStatusINeitherPNorS() { 
    Sample sample = new Sample(); 
    sample.setState("Z"); 
    assertFalse(sample.canBeDeleted()); 
} 

क्या यह परीक्षण उपयोगी है? परीक्षण नामकरण के बारे में क्या? क्या यह तर्क पर्याप्त परीक्षण किया जाएगा?

Answer 1

सेंट थ्रेड आपको एक अच्छा "प्रत्यक्ष" उत्तर दे रहा है।

लेकिन वापस कदम देता है। क्योंकि आप अपने उत्पादन कोड में कुछ गलत कर रहे हैं। सबसे अधिक संभावना है कि, आपका उत्पादन कोड उस स्ट्रिंग पर स्विच की तरह कुछ करता है जो नमूना स्थिति को दर्शाता है। और न केवल एक बार, बल्कि यह सभी विधियों के भीतर प्रदान करता है। और ... यह एक अच्छा ओओ डिजाइन नहीं है!

इसके बजाय, आप बहुरूपता, की तरह उपयोग करना चाहिए:

abstract class Sample { 
    boolean canBeDeleted(); 
// ... probably other methods as well 

और विभिन्न ठोस उपवर्गों साथ

,

class ZSample extends Sample { 
    @Override canBeDeleted() { return false; } 
// ... 

की तरह और अंत में, आप

class SampleFactory { 
    Sample createSampleFrom(String stateIdentifier) { 
    // here you might switch over that string and return a corresponding object, for example of class ZSample 

और फिर है, तो आपकी परीक्षणों को उबाल लें:

1. कारखाने का परीक्षण; इनपुट "जेड" के लिए उदाहरण, यह ZSample
2. नमूना के अपने सभी उप-वर्गों का परीक्षण करने का एक उदाहरण देता है; उदाहरण के लिए कि ZDample हटाया जा सकता है() ZSample

बिंदु के उदाहरण के लिए झूठा रिटर्न देता है: आपका कोड एफएसएम (परिमित राज्य मशीन) का काम करता है। फिर पूरे स्थान पर अगर/elses का उपयोग न करें; इसके बजाय, ओओ चीज करें: एक स्पष्ट राज्य मशीन बनाएं। और, मुफ्त बोनस: यह दृष्टिकोण आपके नमूना वस्तुओं को अपरिवर्तनीय चीज़ों में बदलना भी संभव बनाता है; जो ऑब्जेक्ट्स से निपटने के मुकाबले अक्सर बेहतर होता है जो समय के साथ अपने राज्य को बदल सकता है (क्योंकि अपरिवर्तनीयता उदाहरण के लिए बहु-थ्रेडिंग मुद्दों के साथ बहुत मदद करता है)।

अस्वीकरण: यदि आपका "नमूना" वर्ग केवल उस विधि के बारे में है, तो उपर्युक्त उपरोक्त है। लेकिन किसी भी अन्य मामले में ... शायद वापस कदम और देखें कि मेरे सुझाव आपके डिजाइन में मूल्य जोड़ देंगे!

Answer 2

मेरी राय में आपको चाहिए परीक्षण:

cantBeDeletedWithoutStatus

assertFalse(sample.canBeDeleted()); 

cantBeDeletedWhenStatusIsInvalid

sample.setState("Z"); 
assertFalse(sample.canBeDeleted()); 

cantBeDeletedWhenStatusIsToggledToInvalid

sample.setState("P"); 
sample.setState("Z"); 
assertFalse(sample.canBeDeleted()); 

canBeDeletedWhenStatusIsToggledToS

sample.setState("Z"); 
sample.setState("S"); 
assertFalse(sample.canBeDeleted()); 

canBeDeletedWhenStatusIsToggledToP

sample.setState("Z"); 
sample.setState("P"); 
assertFalse(sample.canBeDeleted()); 

मुझे टिप्पणी में अपने विचार बताएं

Answer 3

हमें अपने परीक्षणों को पूरी तरह से देखना चाहिए, इसलिए उन्हें कई प्रकार के बग का पता लगाने की संभावना है। तो सरल जवाब हाँ है, नो-ऑप केस का परीक्षण करें।

आप यह नहीं बताते कि राज्य के संभावित मूल्य क्या हैं। आइए मान लें कि वे 26 राज्यों को देकर, अंग्रेजी अक्षरों को अपरकेस होना चाहिए। आपका प्रश्न तब अनिवार्य रूप से वही है जैसा "मेरे पास 26 परीक्षण मामले होना चाहिए"। यह बहुत है, लेकिन कई निषिद्ध नहीं है। अब एक और जटिल मामला कल्पना करें, जिसके लिए राज्य एक int है और सभी int मूल्य संभव हैं। उन्हें पूरी तरह से परीक्षण करना अव्यवहारिक होगा। क्या करें?

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