आप टीडीडी में "असली" कोड कब लिखते हैं?

johnny 08/19/2017. 11 answers, 20.464 views
tdd

प्रशिक्षण वीडियो पर मैंने जो कुछ उदाहरण पढ़े और देखे हैं, उनमें सरल उदाहरण हैं। लेकिन मुझे क्या नहीं लगता कि मैं हरा होने के बाद "वास्तविक" कोड कैसे करता हूं। क्या यह "रिएक्टर" हिस्सा है?

यदि मेरे पास एक जटिल विधि के साथ काफी जटिल वस्तु है, और मैं अपना परीक्षण लिखता हूं और इसे न्यूनतम करने के लिए न्यूनतम (इसे पहले विफल करता है, लाल)। मैं वापस कब जाता हूं और असली कोड लिखता हूं? और मैं पुनः प्रयास करने से पहले कितना वास्तविक कोड लिखूं? मुझे लगता है कि आखिरी व्यक्ति अधिक अंतर्ज्ञान है।

Edit: उत्तर देने वाले सभी के लिए धन्यवाद। आपके सभी उत्तरों ने मुझे बहुत मदद की। मैं जो पूछ रहा था या उलझन में था, उसके बारे में अलग-अलग विचार प्रतीत होते हैं, और शायद वहां है, लेकिन मैं जो पूछ रहा था वह कहता था कि मेरे पास स्कूल बनाने के लिए एक आवेदन है।

मेरे डिजाइन में, मेरे पास एक आर्किटेक्चर है जिसे मैं शुरू करना चाहता हूं, उपयोगकर्ता कहानियां, इतनी और आगे। यहां से, मैं उन उपयोगकर्ता कहानियां लेता हूं, और मैं उपयोगकर्ता स्टोरी का परीक्षण करने के लिए एक परीक्षण तैयार करता हूं। उपयोगकर्ता कहता है, हमने लोगों को स्कूल के लिए नामांकन दिया है और पंजीकरण शुल्क का भुगतान किया है। तो, मैं इसे असफल बनाने के तरीके के बारे में सोचता हूं। ऐसा करने में मैं कक्षा X (शायद छात्र) के लिए एक परीक्षा कक्षा तैयार करता हूं, जो असफल हो जाएगा। मैं फिर कक्षा "छात्र" बनाते हैं। शायद "स्कूल" मुझे नहीं पता।

लेकिन, किसी भी मामले में, टीडी Design मुझे कहानी के माध्यम से सोचने के लिए मजबूर कर रहा है। अगर मैं एक परीक्षण विफल कर सकता हूं, तो मुझे पता है कि यह क्यों विफल रहता है, लेकिन यह अनुमान लगाता है कि मैं इसे पास कर सकता हूं। यह डिजाइनिंग के बारे में है।

मैं इसे रिकर्सन के बारे में सोचने के लिए पसंद करता हूं। रिकर्सन एक कठिन अवधारणा नहीं है। वास्तव में अपने सिर में इसका ट्रैक रखना मुश्किल हो सकता है, लेकिन असल में, सबसे कठिन हिस्सा जानना है, जब रिकर्सन "टूटता है," कब रुकना है (मेरी राय, ज़ाहिर है।) तो मुझे क्या रोकना है पहले रिकर्सन। यह केवल एक अपूर्ण समानता है, और यह मानता है कि प्रत्येक पुनरावर्ती पुनरावृत्ति एक "पास" है। फिर, सिर्फ एक राय।

कार्यान्वयन में, स्कूल देखना मुश्किल है। न्यूमेरिकल और बैंकिंग लेजर इस अर्थ में "आसान" हैं कि आप सरल अंकगणितीय का उपयोग कर सकते हैं। मैं एक + बी और 0 लौटा सकता हूं, आदि। लोगों की एक प्रणाली के मामले में, मुझे इसे implement करने के तरीके पर कड़ी मेहनत करनी होगी। मेरे पास असफल, पास, रिफैक्टर (ज्यादातर अध्ययन और इस सवाल के कारण) की अवधारणा है।)

जो मुझे नहीं पता वह मेरी राय में अनुभव की कमी के आधार पर है। मुझे नहीं पता कि कैसे एक नए छात्र को साइन अप करने में विफल होना है। मुझे नहीं पता कि आखिरी नाम में टाइप करने वाले किसी को कैसे विफल किया जाए और इसे किसी डेटाबेस में सहेजा जा रहा है। मुझे पता है कि सरल गणित के लिए + 1 कैसे बनाना है, लेकिन किसी व्यक्ति की तरह इकाइयों के साथ, मुझे नहीं पता कि मैं केवल यह देखने के लिए परीक्षण कर रहा हूं कि क्या मैं डेटाबेस को अद्वितीय आईडी या कुछ और वापस लेता हूं जब कोई व्यक्ति किसी नाम में प्रवेश करता है डेटाबेस या दोनों या न तो।

या, शायद यह दिखाता है कि मैं अभी भी उलझन में हूं।

5 Comments
187 hobbs 07/25/2017
टीडीडी लोग रात के लिए घर जाने के बाद।
14 Goyo 07/25/2017
आपको लगता है कि आपने जो कोड लिखा है वह वास्तविक नहीं है?
2 johnny 07/26/2017
@RubberDuck अन्य उत्तरों से अधिक किया था। मुझे यकीन है कि मैं जल्द ही इसका उल्लेख करूंगा। यह अभी भी विदेशी है, लेकिन मैं इसे छोड़ने वाला नहीं हूं। आपने जो कहा वह समझ में आया। मैं बस अपने संदर्भ या एक नियमित व्यापार आवेदन में इसे समझने की कोशिश कर रहा हूं। शायद एक सूची प्रणाली या पसंद है। मुझे इसे समझना है। हालांकि मैं आपके समय के लिए आभारी हूं। धन्यवाद।
1 Edmund Reed 07/26/2017
उत्तरों ने पहले से ही सिर पर नाखून मारा है, लेकिन जब तक आपके सभी परीक्षण गुज़र रहे हैं, और आपको किसी भी नए परीक्षण / कार्यक्षमता की आवश्यकता नहीं है, तो यह माना जा सकता है कि आपके द्वारा समाप्त किया गया कोड, बार लिनटिंग है।
3 Borjab 07/26/2017
इस सवाल में एक धारणा है कि "जटिल प्रक्रिया के साथ मेरे पास काफी जटिल वस्तु है" में समस्याग्रस्त हो सकता है। टीडीडी में आप पहले अपने परीक्षण लिखते हैं ताकि आप एक काफी सरल कोड से शुरू कर सकें। यह आपको एक परीक्षण-अनुकूल संरचना को कोड करने के लिए मजबूर करेगा जिसे मॉड्यूलर होने की आवश्यकता होगी। सरल वस्तुओं को संयोजित करके जटिल व्यवहार बनाया जाएगा। यदि आप एक काफी जटिल वस्तु या विधि के साथ समाप्त होते हैं तो जब आप रिफैक्टर करते हैं

11 Answers


RubberDuck 07/27/2017.

यदि मेरे पास एक जटिल विधि के साथ काफी जटिल वस्तु है, और मैं अपना परीक्षण लिखता हूं और इसे न्यूनतम करने के लिए न्यूनतम (इसे पहले विफल करता है, लाल)। मैं वापस कब जाता हूं और असली कोड लिखता हूं? और मैं पुनः प्रयास करने से पहले कितना वास्तविक कोड लिखूं? मुझे लगता है कि आखिरी व्यक्ति अधिक अंतर्ज्ञान है।

आप "वापस जाएं" और "असली कोड" नहीं लिखते हैं। यह सब असली कोड है। आप जो करते हैं वह वापस जाता है और एक और परीक्षण जोड़ता है जो आपको नया परीक्षण पास करने के लिए अपना कोड change लिए forces

आपके द्वारा रेट किए जाने से पहले आप कितने कोड लिखते हैं? कोई नहीं। आप असफल परीक्षण के बिना zero कोड लिखते हैं जो आपको अधिक कोड लिखने के लिए forces

पैटर्न पर ध्यान दें?

आइए आशा करते हैं कि यह मदद करता है (दूसरे) सरल उदाहरण के माध्यम से चलते हैं।

 Assert.Equal("1", FizzBuzz(1)); 

आसान आलसी।

 public String FizzBuzz(int n) {
    return 1.ToString();
} 

नहीं, आप असली कोड कहेंगे, है ना? चलो एक परीक्षण जोड़ें जो एक बदलाव को मजबूर करता है।

 Assert.Equal("2", FizzBuzz(2)); 

हम कुछ मूर्खतापूर्ण कर सकते हैं जैसे if n == 1 , लेकिन हम सैने समाधान पर जायेंगे।

 public String FizzBuzz(int n) {
    return n.ToString();
} 

ठंडा। यह सभी गैर-FizzBuzz संख्याओं के लिए काम करेगा। अगला इनपुट क्या है जो उत्पादन कोड को बदलने के लिए मजबूर करेगा?

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
} 

और फिर। एक परीक्षा लिखें जो अभी तक पास नहीं होगी।

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
} 

और अब हमने तीनों के सभी गुणकों को कवर किया है (जो पांच के गुणक भी नहीं हैं, हम इसे नोट करेंगे और वापस आ जाएंगे)।

हमने अभी तक "बज़" के लिए एक टेस्ट नहीं लिखा है, तो चलो इसे लिखें।

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
} 

और फिर, हम जानते हैं कि एक और मामला है जिसे हमें संभालने की जरूरत है।

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
} 

और अब हम 5 के सभी गुणकों को संभाल सकते हैं जो 3 के गुणक भी नहीं हैं।

इस बिंदु तक, हम रिफैक्टरिंग चरण को अनदेखा कर रहे हैं, लेकिन मुझे कुछ डुप्लिकेशन दिखाई देता है। चलो अब इसे साफ़ करें।

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

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

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

परीक्षण पास होते हैं, लेकिन हमारे पास अधिक डुप्लिकेशन है। हमारे पास विकल्प हैं, लेकिन मैं कुछ बार "स्थानीय परिवर्तनीय निकालें" लागू करने जा रहा हूं ताकि हम पुनर्लेखन के बजाय पुनः प्रतिक्रिया कर रहे हों।

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

और हमने हर उचित इनपुट को कवर किया है, लेकिन unreasonable इनपुट के बारे में क्या? अगर हम 0 या नकारात्मक पास करते हैं तो क्या होता है? उन परीक्षण मामलों को लिखें।

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

क्या यह अभी तक "असली कोड" जैसा दिखने लग रहा है? सबसे महत्वपूर्ण बात यह है कि किस बिंदु पर "असत्य कोड" और "असली" होने के संक्रमण में बदलाव आया? यह सोचने के लिए कुछ है ...

तो, मैं बस एक परीक्षण की तलाश करके ऐसा करने में सक्षम था जो मुझे पता था कि प्रत्येक चरण में नहीं होगा, लेकिन मेरे पास बहुत सारी अभ्यास है। जब मैं काम पर हूं, चीजें कभी भी सरल नहीं होतीं और मुझे हमेशा यह नहीं पता कि कौन सा परीक्षण बदलाव को मजबूर करेगा। कभी-कभी मैं एक परीक्षा लिखूंगा और यह देखकर आश्चर्यचकित हो जाऊंगा कि यह पहले से ही गुजरता है! मैं अत्यधिक अनुशंसा करता हूं कि आप शुरू करने से पहले "टेस्ट लिस्ट" बनाने की आदत में आएं। इस परीक्षण सूची में उन सभी "रोचक" इनपुट शामिल हो सकते हैं जिन्हें आप सोच सकते हैं। आप उन सभी का उपयोग नहीं कर सकते हैं और आप जैसे ही जाते हैं, आप संभावित रूप से मामले जोड़ सकते हैं, लेकिन यह सूची रोडमैप के रूप में कार्य करती है। FizzBuzz के लिए मेरी टेस्ट सूची इस तरह कुछ दिखाई देगी।

  • नकारात्मक
  • शून्य
  • एक
  • दो
  • तीन
  • चार
  • पंज
  • छह (3 के गैर तुच्छ बहु)
  • नौ (3 वर्ग)
  • दस (5 के गैर तुच्छ बहु)
  • 15 (3 और 5 के एकाधिक)
  • 30 (3 और 5 के गैर तुच्छ बहु)
5 comments
3 maple_shaft♦ 07/27/2017
टिप्पणियां विस्तारित चर्चा के लिए नहीं हैं; इस बातचीत को चैट करने के लिए ले जाया गया है
40 GManNickG 07/27/2017
जब तक मैं इस जवाब को पूरी तरह से गलत समझ नहीं पा रहा हूं: "हम कुछ मूर्खतापूर्ण तरीके कर सकते हैं जैसे कि n == 1, लेकिन हम सैने समाधान पर जायेंगे।" - पूरी बात बेवकूफ थी। यदि आप आगे जानते हैं तो आप एक ऐसा फ़ंक्शन चाहते हैं जो <spec> करता है, <spec> के लिए परीक्षण लिखें और उस भाग को छोड़ दें जहां आप संस्करण लिखते हैं जो स्पष्ट रूप से विफल हो जाता है <spec>। यदि आपको <spec> में कोई बग मिलती है तो सुनिश्चित करें: यह सत्यापित करने के लिए पहले एक परीक्षण लिखें कि आप इसे ठीक से पहले प्रयोग कर सकते हैं और फिक्स के बाद परीक्षण पास का निरीक्षण कर सकते हैं। लेकिन इन सभी मध्यवर्ती कदमों को नकली करने की कोई आवश्यकता नहीं है।
15 user3791372 07/28/2017
टिप्पणियां जो इस उत्तर में प्रमुख त्रुटियों को इंगित करती हैं और सामान्य रूप से टीडीडी को चैट करने के लिए स्थानांतरित कर दी गई हैं। यदि आप टीडीडी का उपयोग करने पर विचार कर रहे हैं, तो कृपया 'चैट' पढ़ें। दुर्भाग्य से भविष्य में छात्रों को पढ़ने के लिए चैट की लोड के बीच 'गुणवत्ता' टिप्पणियां अब छिपी हुई हैं।
nbro 07/28/2017
यदि आप इस उत्तर को बेहतर बनाना चाहते हैं, तो मैं इस "परीक्षण सूची" की सामग्री के बारे में अधिक सटीक होगा। मैं स्पष्ट रूप से "सीमा मान" और "वर्ग विभाजन" के बारे में बात करता हूं।
2 hvd 07/30/2017
@GManNickG मेरा मानना ​​है कि सही मात्रा में परीक्षण प्राप्त करना है। परीक्षणों को पहले से लिखना आसान है कि कौन से विशेष मामलों का परीक्षण किया जाना चाहिए, या तो परीक्षणों में पर्याप्त रूप से कवर नहीं होने वाली परिस्थितियों में या अनिवार्य रूप से उसी स्थिति में परीक्षणों में व्यर्थ रूप से कवर किए जाने वाले भारों के कारण होता है। यदि आप इन मध्यवर्ती चरणों के बिना ऐसा कर सकते हैं, तो बढ़िया! हर कोई ऐसा नहीं कर सकता है, फिर भी, यह कुछ ऐसा है जो अभ्यास लेता है।

GenericJon 07/24/2017.

"वास्तविक" कोड वह कोड है जिसे आप अपना परीक्षण पास करने के लिए लिखते हैं। Really यह इत्ना आसान है।

जब लोग टेस्ट हरे रंग के लिए न्यूनतम लिखने के बारे में बात करते हैं, तो इसका मतलब है कि आपका असली कोड YAGNI सिद्धांत का पालन करना चाहिए।

रिफैक्टर चरण का विचार सिर्फ एक बार लिखा है जब आप खुश हैं कि यह आवश्यकताओं को पूरा करता है।

जब तक आप लिखने वाले परीक्षणों में वास्तव में आपके उत्पाद की आवश्यकताओं को शामिल करते हैं, एक बार वे गुजरने के बाद कोड पूरा हो जाता है। इसके बारे में सोचें, अगर आपकी सभी व्यावसायिक आवश्यकताओं के पास परीक्षण है और वे सभी परीक्षण हरे हैं, तो लिखने के लिए और क्या है? (ठीक है, वास्तविक जीवन में हमारे पास पूर्ण परीक्षण कवरेज नहीं है, लेकिन सिद्धांत ध्वनि है।)

5 comments
44 Derek Elkins 07/24/2017
यूनिट परीक्षण वास्तव में अपेक्षाकृत मामूली आवश्यकताओं के लिए आपकी उत्पाद आवश्यकताओं को शामिल नहीं कर सकते हैं। सबसे अच्छा, वे इनपुट-आउटपुट स्पेस का नमूना देते हैं और विचार यह है कि आप (सही ढंग से) पूर्ण इनपुट-आउटपुट स्पेस को सामान्यीकृत करते हैं। बेशक, आपका कोड प्रत्येक यूनिट परीक्षण के मामले के साथ एक बड़ा switch हो सकता है जो सभी परीक्षणों को पारित करेगा और किसी भी अन्य इनपुट के लिए असफल होगा।
8 Taemyr 07/25/2017
@DerekElkins टीडीडी अनिवार्य परीक्षणों को जनादेश देता है। इकाई परीक्षण में असफल नहीं।
6 jonrsharpe 07/25/2017
@DerekElkins यही कारण है कि आप केवल यूनिट परीक्षण नहीं लिखते हैं, और यह भी एक सामान्य धारणा है कि आप कुछ नकली नहीं बनाने की कोशिश कर रहे हैं!
35 Derek Elkins 07/25/2017
@jonrsharpe उस तर्क से, मैं कभी भी छोटे कार्यान्वयन नहीं लिखूंगा। जैसे कि रबरबक के उत्तर में फिजबज़ उदाहरण में (जो केवल यूनिट परीक्षणों का उपयोग करता है), पहला कार्यान्वयन स्पष्ट रूप से "बस इसे नकल करता है"। प्रश्न की मेरी समझ वास्तव में लेखन कोड के बीच यह डिचोटोमी है जिसे आप जानते हैं अधूरा और कोड जिसे आप वास्तव में विश्वास करते हैं, आवश्यकता को लागू करेंगे, "असली कोड"। मेरा "बड़ा switch " का उद्देश्य तार्किक चरम के रूप में किया गया था "परीक्षणों को हरा बनाने के लिए न्यूनतम न्यूनतम लिखना"। मैं ओपी के सवाल को इस प्रकार देखता हूं: जहां टीडीडी सिद्धांत है जो इस बड़े switch से बचाता है?
2 Luaan 07/25/2017
@GenericJon यह मेरे अनुभव में थोड़ा सा आशावादी है :) एक के लिए, ऐसे लोग हैं जो दिमागी दोहराव वाले काम का आनंद लेते हैं। वे "जटिल निर्णय लेने" की तुलना में एक विशाल स्विच स्टेटमेंट के साथ खुश होंगे। और अपनी नौकरी खोने के लिए, उन्हें या तो किसी ऐसे व्यक्ति की आवश्यकता होगी जो उन्हें तकनीक पर बुलाए (और उनके पास अच्छे सबूत हैं कि यह वास्तव में कंपनी के अवसर / धन खो रहा है!), या असाधारण रूप से बुरी तरह से करें। ऐसी कई परियोजनाओं पर रखरखाव करने के बाद, मैं बता सकता हूं कि बहुत ही भयानक कोड दशकों तक चलना आसान है, जब तक कि यह ग्राहक खुश (और भुगतान) करता है।

Carl Raymond 07/24/2017.

संक्षिप्त जवाब यह है कि "असली कोड" वह कोड है जो परीक्षण पास करता है। यदि आप वास्तविक कोड के अलावा किसी अन्य चीज़ के साथ अपना परीक्षण पास कर सकते हैं, तो अधिक परीक्षण जोड़ें!

मैं मानता हूं कि टीडीडी के बारे में बहुत सारे ट्यूटोरियल सरल हैं। यह उनके खिलाफ काम करता है। एक विधि के लिए एक बहुत ही सरल परीक्षण, कहता है, 3 + 8 की गणना करता है वास्तव में 3 + 8 की गणना करने और परिणाम की तुलना करने के अलावा कोई विकल्प नहीं है। इससे ऐसा लगता है कि आप बस पूरे कोड को डुप्लिकेट कर देंगे, और यह परीक्षण व्यर्थ, त्रुटि-प्रवण अतिरिक्त कार्य है।

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

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

4 comments
6 Steve Jessop 07/26/2017
व्यक्तिगत रूप से, जो परीक्षण मैं लिखूंगा वह assertEqual(plus(3,8), 11) होगा assertEqual(plus(3,8), 11) , assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) नहीं assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) । अधिक जटिल मामलों के लिए, आप परीक्षण में सही परिणाम की गणना और समानता की जांच करने के other than , परिणाम को सही साबित करने के साधनों को हमेशा सही तरीके other than
Steve Jessop 07/26/2017
तो इस उदाहरण के लिए इसे करने का वास्तव में मूर्ख तरीके से, आप साबित कर सकते हैं कि plus(3,8) ने 3 से घटाकर सही परिणाम वापस कर दिया है, उसमें से 8 घटाकर, और 0 के विरुद्ध परिणाम की जांच कर रहा है। यह स्पष्ट रूप से है assertEqual(plus(3,8), 3+8) बराबर assertEqual(plus(3,8), 3+8) थोड़ा बेतुका होने के लिए, लेकिन यदि परीक्षण के तहत कोड केवल एक पूर्णांक की तुलना में कुछ जटिल बना रहा है, तो परिणाम लेना और शुद्धता के लिए प्रत्येक भाग की जांच करना अक्सर होता है सही दृष्टिकोण। वैकल्पिक रूप से, कुछ for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
... क्योंकि इससे बड़े डर से बचा जाता है, जो कि परीक्षण लिखते समय हम लाइव कोड में "10 कैसे जोड़ सकते हैं" के विषय पर एक ही गलती करेंगे। इसलिए परीक्षण सावधानीपूर्वक किसी भी कोड को लिखने से बचाता है जो 10 में कुछ भी जोड़ता है, परीक्षण में plus() चीजों को 10 जोड़ सकता है। हम अभी भी प्रोग्रामर-सत्यापित इंटियल लूप मानों पर भरोसा करते हैं।
3 Warbo 07/28/2017
बस यह इंगित करना चाहते हैं कि भले ही आप तथ्य के बाद परीक्षण लिख रहे हों, फिर भी उन्हें असफल देखना एक अच्छा विचार है; कोड का कुछ हिस्सा ढूंढें जो आप जो कुछ भी कर रहे हैं उसके लिए महत्वपूर्ण लगता है, इसे थोड़ा छोटा करें (उदाहरण के लिए एक +, या जो भी हो) को बदलें, परीक्षण चलाएं और उन्हें असफल देखें, बदलाव को पूर्ववत करें और उन्हें पास करें। कई बार मैंने यह किया है कि परीक्षण वास्तव में असफल नहीं होता है, इसे बेकार से भी बदतर बना देता है: न केवल यह कुछ भी परीक्षण नहीं कर रहा है, यह मुझे झूठा विश्वास दे रहा है कि कुछ परीक्षण किया जा रहा है!

Victor Cejudo 07/25/2017.

कभी-कभी टीडीडी के बारे में कुछ उदाहरण भ्रामक हो सकते हैं। जैसा कि अन्य लोगों ने पहले बताया है, कोड जो आप लिखने के लिए लिखते हैं वह असली कोड है।

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

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

बॉब मार्टिन इसे पूरी तरह से यहां बताते हैं


CandiedOrange 07/25/2017.

जब आप थक जाते हैं और घर जाना चाहते हैं तो रिफैक्टर भाग साफ हो जाता है।

जब आप एक फीचर जोड़ने जा रहे हैं तो रेफैक्टर भाग वह है जिसे आप अगले टेस्ट से पहले बदलते हैं। आप नई सुविधा के लिए जगह बनाने के लिए कोड को दोबारा प्रतिक्रिया देते हैं। जब आप know कि वह नई सुविधा क्या होगी, तो आप ऐसा करते हैं। जब आप इसे कल्पना नहीं कर रहे हैं।

यह "हाय मॉम" प्रिंट करने वाली सुविधा जोड़ने के लिए GreetMom क्लास (परीक्षण जोड़ने के बाद) बनाने से पहले GreetImpl को GreetWorld को नाम GreetImpl के GreetWorld सरल हो सकता है।


graeme 07/27/2017.

लेकिन असली कोड टीडीडी चरण के रिफैक्टर चरण में दिखाई देगा। मैं कोड जो अंतिम रिलीज का हिस्सा होना चाहिए।

हर बार जब आप बदलाव करते हैं तो टेस्ट चलाना चाहिए।

टीडीडी जीवन चक्र का आदर्श होगा: लाल ग्रीन रिएक्टर

RED : परीक्षण लिखें

GREEN : कार्यात्मक कोड प्राप्त करने के लिए एक ईमानदार प्रयास करें जो जितनी जल्दी हो सके परीक्षण पास करता है: डुप्लिकेट कोड, अस्पष्ट रूप से नामित चर उच्चतम क्रम के हैक आदि।

REFACTOR : कोड को साफ करें, चर का सही नाम दें। कोड को ड्रॉ करें

5 comments
5 mcottle 07/25/2017
मुझे पता है कि आप "ग्रीन" चरण के बारे में क्या कह रहे हैं लेकिन इसका तात्पर्य है कि टेस्ट पास करने के लिए हार्ड-वायरिंग रिटर्न वैल्यू उचित हो सकते हैं। मेरे अनुभव में "ग्रीन" आवश्यकता को पूरा करने के लिए कामकाजी कोड बनाने का एक ईमानदार प्रयास होना चाहिए, यह सही नहीं हो सकता है लेकिन यह पूर्ण और "शिप करने योग्य" होना चाहिए क्योंकि डेवलपर पहले पास में प्रबंधित कर सकता है। कुछ और बाद में रिफैक्टरिंग संभवतः अधिक विकास करने के बाद किया जाता है और पहले पास की समस्याएं अधिक स्पष्ट हो जाती हैं और डीआरवाई उभरने के अवसर बन जाते हैं।
graeme 07/25/2017
@mcottle मैं एक ही कार्य के इन सभी भागों पर विचार करता हूं। इसे पूरा करें, फिर इसे साफ करें। अन्य कार्यों के हिस्से के रूप में समय चलने के साथ ही आगे की प्रतिक्रियाएं होनी चाहिए।
1 Bryan Boettcher 07/25/2017
@mcottle: आप आश्चर्यचकित हो सकते हैं कि केवल एकमात्र भंडार के कितने कार्यान्वयन कोडेबेस में हार्डकोड किए गए मान हो सकते हैं। :)
6 Kaz 07/25/2017
मैं कभी भी बकवास कोड क्यों लिखूंगा और इसे साफ़ कर दूंगा, जब मैं अच्छा कर सकता हूं, उत्पादन गुणवत्ता कोड लगभग जितना तेज़ हो सकता हूं? :)
1 Kaz 07/27/2017
@TimothyTruckle सबसे आसान संभव परिवर्तन खोजने के लिए 50 मिनट लगते हैं, लेकिन दूसरा सबसे आसान संभव परिवर्तन खोजने के लिए केवल 5? क्या हम दूसरे सबसे सरल के साथ जाते हैं या सबसे सरल खोजते रहते हैं?

Timothy Truckle 07/27/2017.

आप टीडीडी में "असली" कोड कब लिखते हैं?

red चरण वह जगह है जहां आप कोड write

refactoring चरण में प्राथमिक लक्ष्य कोड को delete

red चरण में आप as quick as possible और at any cost परीक्षण पास करने के लिए कुछ भी कर सकते हैं। आप पूरी तरह से अच्छी कोडिंग प्रथाओं या डिजाइन पैटर्न के बारे में जो कुछ भी सुना है, उसे पूरी तरह से अवहेलना करते हैं। परीक्षण हरा बनाना सब कुछ मायने रखता है।

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

अंत में आप पहचानकर्ताओं का नाम बदलकर और स्थिरांक में magic numbers और / या शाब्दिक तारों को निकालने के द्वारा पठनीयता में सुधार करते हैं।


यह लाल-रिएक्टर नहीं है, यह लाल-हरा-रिफैक्टर है। - रॉब किनीन

इस पर इशारा करने के लिए धन्यवाद।

तो यह green चरण है जहां आप real code लिखते हैं

red चरण में आप executable specification लिखते हैं ...

2 comments
Rob Kinyon 07/27/2017
यह लाल-रिएक्टर नहीं है, यह लाल-हरा-रिफैक्टर है। "लाल" क्या आप अपना टेस्ट सूट हरा (सभी परीक्षण पास) से लाल (एक परीक्षण विफल रहता है) से लेते हैं। "हरा" वह जगह है जहां आप अपने टेस्ट सूट को लाल से (एक परीक्षण विफल) हरे रंग में ले जाते हैं (सभी परीक्षण पास होते हैं)। "रिफैक्टर" वह जगह है जहां आप अपना कोड लेते हैं और सभी परीक्षणों को पार करते हुए इसे सुंदर बनाते हैं।
Timothy Truckle 07/27/2017
@RobKinyon धन्यवाद, उत्तर अद्यतन किया।

Robert Andrzejuk 07/27/2017.

आप पूरे समय Real Code लिख रहे हैं।

प्रत्येक चरण में आप उन शर्तों को पूरा करने के लिए कोड लिख रहे हैं जो आपका कोड आपके कोड के भविष्य के कॉलर्स के लिए संतुष्ट होगा (जो आप हो या नहीं ...)।

आपको लगता है कि आप उपयोगी ( real ) कोड नहीं लिख रहे हैं, क्योंकि एक पल में आप इसे फिर से समझ सकते हैं।

कोड-रिफैक्टरिंग मौजूदा कंप्यूटर कोड को पुनर्गठन की प्रक्रिया है-फैक्टरिंग को बदलना-इसके बाहरी व्यवहार को बदले बिना।

इसका अर्थ यह है कि भले ही आप कोड बदल रहे हों, कोड को संतृप्त करने की स्थितियों को अपरिवर्तित छोड़ दिया गया है। और चेक ( tests ) आपने यह सत्यापित करने के लिए लागू किया है कि आपका कोड पहले से ही यह सत्यापित करने के लिए है कि आपके संशोधनों में कुछ बदलाव आया है या नहीं। तो जिस कोड को आपने पूरा समय लिखा है, वह बिल्कुल अलग तरीके से है।

एक अन्य कारण आपको लगता है कि यह वास्तविक कोड नहीं है, यह है कि आप ऐसे उदाहरण कर रहे हैं जहां अंत प्रोग्राम आपके द्वारा पहले से ही जा सकता है। यह बहुत अच्छा है, क्योंकि यह दिखाता है कि आपको उस domain बारे में ज्ञान है जिसमें आप प्रोग्रामिंग कर रहे हैं।
लेकिन कई बार प्रोग्रामर ऐसे domain में होते हैं जो new , उनके लिए unknown है। वे नहीं जानते कि अंतिम परिणाम क्या होगा और टीडीडी चरण-दर-चरण प्रोग्राम लिखने की technique है, इस प्रणाली को कैसे काम करना चाहिए और यह सत्यापित करना कि हमारे कोड इस तरह से काम करते हैं, इस बारे में हमारे knowledge दस्तावेज करते हैं।

जब मैंने टीडीडी पर पुस्तक (*) पढ़ी, तो मेरे लिए सबसे महत्वपूर्ण विशेषता जो थी: TODO सूची थी। यह मुझे दिखाता है कि, टीडीडी एक तकनीक है जो डेवलपर्स को एक समय में एक चीज़ पर ध्यान केंद्रित करने में मदद करने के लिए एक तकनीक है। तो यह आपके प्रश्न का उत्तर भी है कि How much Real code to write ? मैं एक समय में 1 चीज़ पर ध्यान केंद्रित करने के लिए पर्याप्त कोड कहूंगा।

(*) केंट बेक द्वारा "परीक्षण संचालित विकास: उदाहरण के द्वारा"

1 comments
2 Robert Andrzejuk 07/27/2017
केंट बेक द्वारा "परीक्षण संचालित विकास: उदाहरण के द्वारा"

Zenilogix 07/31/2017.

आप अपने परीक्षण विफल करने के लिए कोड नहीं लिख रहे हैं।

आप अपने परीक्षणों को परिभाषित करने के लिए लिखते हैं कि सफलता किस तरह दिखनी चाहिए, जो सभी प्रारंभ में विफल होनी चाहिए क्योंकि आपने अभी तक कोड नहीं लिखा है।

प्रारंभिक रूप से असफल परीक्षण लिखने के बारे में पूरा बिंदु दो चीजें करना है:

  1. सभी मामलों को कवर करें - सभी नाममात्र मामले, सभी किनारे के मामलों आदि।
  2. अपने परीक्षणों को मान्य करें। यदि आप उन्हें कभी भी पास करते हैं, तो आप कैसे सुनिश्चित कर सकते हैं कि जब कोई होता है तो वे विश्वसनीय रूप से विफलता की रिपोर्ट करेंगे?

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

अपने अनुभव (सी # / एनईटी) में, शुद्ध परीक्षण-पहला एक अटूट आदर्श है, क्योंकि आप किसी विधि को कॉल संकलित नहीं कर सकते हैं जो अभी तक मौजूद नहीं है। तो "टेस्ट फर्स्ट" वास्तव में इंटरफेस को कोडिंग और पहले कार्यान्वयन को रोकने के बारे में है, फिर स्टब्स के खिलाफ परीक्षण लिखना (जो प्रारंभ में विफल हो जाएगा) जब तक स्टब्स ठीक से बाहर नहीं हो जाते हैं। मैं कभी भी "विफल कोड" लिख रहा हूं, बस स्टब्स से बाहर निकलना।


Zan Lynx 07/27/2017.

मुझे लगता है कि आप यूनिट परीक्षण और एकीकरण परीक्षणों के बीच भ्रमित हो सकते हैं। मेरा मानना ​​है कि स्वीकृति परीक्षण भी हो सकते हैं, लेकिन यह आपकी प्रक्रिया पर निर्भर करता है।

एक बार जब आप सभी छोटी "इकाइयों" का परीक्षण कर लेंगे तो आप उन सभी को इकट्ठा करेंगे, या "एकीकृत"। यह आमतौर पर एक संपूर्ण कार्यक्रम या पुस्तकालय है।

कोड में मैंने एकीकरण लिखा है जिसमें विभिन्न परीक्षण कार्यक्रमों के साथ लाइब्रेरी है जो डेटा पढ़ती है और इसे लाइब्रेरी में फ़ीड करती है, फिर परिणाम जांचें। तब मैं धागे के साथ करता हूँ। फिर मैं इसे बीच में धागे और कांटा () के साथ करता हूं। फिर मैं इसे चलाता हूं और 2 सेकंड के बाद -9 को मारता हूं, फिर मैं इसे शुरू करता हूं और इसकी पुनर्प्राप्ति मोड की जांच करता हूं। मैं इसे फजी करता हूँ। मैं इसे सभी तरह के तरीकों से यातना देता हूं।

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

यही वह जगह है जहां आप "वास्तविक कोड" का परीक्षण करते हैं।

और मैंने बस इसके बारे में सोचा, लेकिन शायद आपको नहीं पता कि आपको यूनिट परीक्षण लिखने के लिए कब माना जाता है। जब आप अपने परीक्षणों को निर्दिष्ट करते हैं तो आपको यूनिट परीक्षण लिखते हैं। कभी-कभी आप सभी त्रुटि प्रबंधन और किनारे के मामलों में से इसका ट्रैक खो सकते हैं, इसलिए हो सकता है कि आप खुश पथ परीक्षणों का एक अच्छा परीक्षण समूह बनाना चाहें जो सीधे विनिर्देशों के माध्यम से सीधे जाएं।

1 comments
Peter Mortensen 07/27/2017
(इसका = स्वामित्व वाला, यह = "यह है" या "यह है"। उदाहरण के लिए देखें How to Use Its and It's ।)

user3791372 07/27/2017.

प्रश्न के शीर्षक के जवाब में: "आप टीडीडी में" असली "कोड कब लिखते हैं?", जवाब है: 'शायद ही कभी' या 'बहुत धीरे-धीरे'।

आप एक छात्र की तरह लगते हैं, इसलिए मैं जवाब दूंगा जैसे कि एक छात्र को सलाह देना।

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

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

लेकिन आपको यह जानना होगा कि सभ्य कोड डिज़ाइन करने में सक्षम होने के लिए अपने एप्लिकेशन को कैसे तोड़ना है। उदाहरण के लिए, यदि आपको लिटिल बॉबी टेबल (xkcd 327) के बारे में पता नहीं था, तो शायद आप डेटाबेस के साथ काम करने से पहले अपने इनपुट को स्वच्छ नहीं कर पाएंगे, इसलिए आप उस अवधारणा के आसपास अपना डेटा सुरक्षित नहीं कर पाएंगे।

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

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

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

5 comments
3 johnny 07/25/2017
मैं एक छात्र के करीब भी नहीं हूं, लेकिन मैं पढ़ता हूं और अच्छी तकनीकें लागू करने और पेशेवर बनने की कोशिश करता हूं। तो उस अर्थ में, मैं एक "छात्र" हूं। मैं बस बहुत ही बुनियादी सवाल पूछता हूं क्योंकि मैं वही हूं। मुझे यह जानना अच्छा लगता है कि मैं ऐसा क्यों कर रहा हूं जो मैं कर रहा हूं। इस मामले का दिल। अगर मुझे यह नहीं मिलता है, तो मुझे यह पसंद नहीं है और सवाल पूछना शुरू करें। मुझे यह जानने की ज़रूरत है कि क्यों, अगर मैं इसका इस्तेमाल करने जा रहा हूं। टीडीडी कुछ तरीकों से सहजता से अच्छा लगता है जैसे कि आपको चीजों को बनाने और सोचने की आवश्यकता है, लेकिन कार्यान्वयन को समझना मुश्किल था। मुझे लगता है कि अब मुझे बेहतर समझ है।
4 Sean Burton 07/27/2017
वे टीडीडी के नियम हैं। हालांकि आप कोड लिखने के लिए स्वतंत्र हैं, लेकिन यदि आप उन तीन नियमों का पालन नहीं करते हैं तो आप टीडीडी नहीं कर रहे हैं।
2 user3791372 07/27/2017
एक व्यक्ति के "नियम"? टीडीडी एक धर्म है, न कि धर्म की मदद करने के लिए एक सुझाव है। यह देखकर दुख की बात है कि इतने सारे लोग एक विचार का पालन करते हैं। यहां तक ​​कि टीडीडी की उत्पत्ति भी विवादास्पद है।
2 Alex 07/28/2017
@ user3791372 टीडीडी एक बहुत सख्त और स्पष्ट रूप से परिभाषित प्रक्रिया है। यहां तक ​​कि अगर कई सोचते हैं कि इसका मतलब यह है कि "प्रोग्रामिंग करते समय कुछ परीक्षण करें", ऐसा नहीं है। आइए यहां शब्दों को मिश्रण न करने का प्रयास करें, यह प्रश्न टीडीडी प्रक्रिया के बारे में है, सामान्य परीक्षण नहीं।

HighResolutionMusic.com - Download Hi-Res Songs

1 (G)I-DLE

POP/STARS flac

(G)I-DLE. 2018. Writer: Riot Music Team;Harloe.
2 Ariana Grande

​Thank U, Next flac

Ariana Grande. 2018. Writer: Crazy Mike;Scootie;Victoria Monét;Tayla Parx;TBHits;Ariana Grande.
3 Imagine Dragons

Bad Liar flac

Imagine Dragons. 2018. Writer: Jorgen Odegard;Daniel Platzman;Ben McKee;Wayne Sermon;Aja Volkman;Dan Reynolds.
4 Clean Bandit

Baby flac

Clean Bandit. 2018. Writer: Jack Patterson;Kamille;Jason Evigan;Matthew Knott;Marina;Luis Fonsi.
5 BlackPink

Kiss And Make Up flac

BlackPink. 2018. Writer: Soke;Kny Factory;Billboard;Chelcee Grimes;Teddy Park;Marc Vincent;Dua Lipa.
6 Kelly Clarkson

Never Enough flac

Kelly Clarkson. 2018. Writer: Benj Pasek;Justin Paul.
7 Backstreet Boys

Chances flac

Backstreet Boys. 2018.
8 BTS

Waste It On Me flac

BTS. 2018. Writer: Steve Aoki;Jeff Halavacs;Ryan Ogren;Michael Gazzo;Nate Cyphert;Sean Foreman;RM.
9 Bradley Cooper

Always Remember Us This Way flac

Bradley Cooper. 2018. Writer: Lady Gaga;Dave Cobb.
10 Mako

Rise flac

Mako. 2018. Writer: Riot Music Team;Mako;Justin Tranter.
11 Halsey

Without Me flac

Halsey. 2018. Writer: Halsey;Delacey;Louis Bell;Amy Allen;Justin Timberlake;Timbaland;Scott Storch.
12 Lady Gaga

I'll Never Love Again flac

Lady Gaga. 2018. Writer: Benjamin Rice;Lady Gaga.
13 Little Mix

Told You So flac

Little Mix. 2018. Writer: Eyelar;MNEK;Raye.
14 Haley Reinhart

Something Strange flac

Haley Reinhart. 2018.
15 Little Mix

Woman Like Me flac

Little Mix. 2018. Writer: Nicki Minaj;Steve Mac;Ed Sheeran;Jess Glynne.
16 Bradley Cooper

Shallow flac

Bradley Cooper. 2018. Writer: Andrew Wyatt;Anthony Rossomando;Mark Ronson;Lady Gaga.
17 Diplo

Close To Me flac

Diplo. 2018. Writer: Ellie Goulding;Savan Kotecha;Peter Svensson;Ilya;Swae Lee;Diplo.
18 Imagine Dragons

Machine flac

Imagine Dragons. 2018. Writer: Wayne Sermon;Daniel Platzman;Dan Reynolds;Ben McKee;Alex Da Kid.
19 KSHMR

Magic flac

KSHMR. 2018.
20 Call Me Karizma

God Damnit flac

Call Me Karizma. 2018. Writer: Illenium;Call Me Karizma.

Related questions

Hot questions

Language

Popular Tags