TDD, AI Agents and Coding - Kent Beck

gogokow27 · 2025-06-15T00:31:56+09:00

Kent Beck का परिचय Extreme Programming (XP) के संस्थापक Agile Manifesto के सह-लेखक (वर्णक्रमानुसार पहले हस्ताक्षरकर्ता) TDD (Test-Driven Development) के अग्रदूत 52 साल के coding अनुभव वाले इंडस्ट्री के दिग्गज फिलहाल "Tidy Together" (software design और teamwork) लिख रहे हैं रोज़ 6-10 घंटे से अधिक AI tools के साथ coding करते हुए "सबसे आनंददायक programming का दौर" जी रहे हैं 1. AI coding tools और 'genie' की उपमा मुख्य अवधारणा: अप्रत्याशित genie AI agents की तुलना "अप्रत्याशित genie" से "यह ठीक वही नहीं करता जो मैं कहना चाहता हूँ" "इनका अपना एजेंडा होता है" AI के साथ काम करने का अनुभव सकारात्मक पक्ष: कभी-कभी जादू की तरह बड़े design problems हल कर देता है अनपेक्षित लेकिन उपयोगी features लागू कर देता है (जैसे: B+ tree stress tester) नकारात्मक पक्ष: user intent को गलत समझ लेता है tests को delete या modify करने की कोशिश करता है lookup table से समस्या को "हल" करने जैसी शरारती हरकतें करता है लत जैसी अनुभूति slot machine जैसी intermittent reward "रात में कंप्यूटर के पास से गुजरते हुए सोचता हूँ, 'एक prompt और करके देखूँ?'" "एक घंटे वाला prompt शुरू करके बाहर निकल जाता हूँ" 2. AI युग में skills का बदलाव skill value का पुनर्गठन "90% skills अपनी value खो देती हैं, और 10% skills की value 1000 गुना बढ़ जाती है" जिन skills की value बढ़ी: vision सेट करना milestone management complexity control जिन skills की value घटी: language-specific details (जैसे Rust में &, *, [] की position) programming languages पर नज़रिये में बदलाव पहले: Smalltalk के प्रति गहरा भावनात्मक लगाव अब: "इतनी बार दिल टूट चुका है" कि language attachment खत्म हो गया "Java developer", "Clojure developer" जैसी पहचान-आधारित विभाजन से थकान "osmosis learning": AI की वजह से language details जाने बिना भी programming संभव हाल में आज़माई गई languages: Swift, Go, Rust, Haskell, C++, JavaScript मौजूदा महत्वाकांक्षी project: Server Smalltalk persistent: database की तरह काम करता है transactional: commit और abort संभव parallelism: multi-threading और machines के बीच parallel processing large-scale data प्रोसेसिंग 3. Agile Manifesto का इतिहास जन्म की पृष्ठभूमि (2001) waterfall model के विकल्प की तलाश कई वर्षों के software methodology workshops का परिणाम Norway cruise की तैयारी वाली बैठक → Utah में अंतिम बैठक Kent Beck का योगदान "daily" शब्द जोड़ा (12 principles में "daily interaction") वर्णक्रम के हिसाब से पहले हस्ताक्षरकर्ता "agile" शब्द से असंतोष समस्या: यह "बहुत आकर्षक" था, इसलिए उम्मीद थी कि हर organization इसका दुरुपयोग करेगी सच में principles फॉलो किए बिना भी खुद को agile कहने वाली organizations सामने आईं पसंदीदा विकल्प: "conversational" one-way नहीं, two-way communication पर ज़ोर पर्याप्त आकर्षक न होने से अपनाया नहीं गया 4. Extreme Programming (XP) शुरुआत की पृष्ठभूमि शुरुआती consulting अनुभव: शुरुआत में technical consultant थे (performance tuning, bit manipulation) project management advice की माँग बढ़ी environment की अहमियत की खोज: सिर्फ seating बदलने से भी नाटकीय सुधार Chrysler project: असफल हो रहे project को सफलता में बदला असरदार सभी practices को "सबसे ऊँचे स्तर (11 तक)" ले गए XP के मूल सिद्धांत चार activities को समय के छोटे-छोटे हिस्सों में बाँटकर साथ-साथ/क्रमिक रूप से करना: क्या करना है समझना किस structure में करना है design करना feature implement करना उम्मीद के मुताबिक काम कर रहा है या नहीं जाँचना pair programming अनिवार्य नहीं, बल्कि प्रयोगधर्मी approach शुरुआती team अनुभव: development के बाद मिले सभी bugs solo work के code में थे "pair programming में production defects शून्य थे" naming की रणनीति "extreme" चुनने का कारण: प्रतिस्पर्धी (Grady Booch) ऐसा उकसाने वाला नाम इस्तेमाल नहीं करेंगे extreme sports के लोकप्रिय दौर से भी मेल खा गया "extreme athletes या तो बेहतरीन तैयारी करते हैं, या मरते हैं" - एक अच्छा रूपक सफलता के कारण dot-com bubble के दौर में 18 महीने की waterfall पद्धति से निराश developers को आकर्षित किया तेज़ और अधिक predictable results का वादा 5. Test-Driven Development (TDD) उत्पत्ति और प्रेरणा (1970s) tape-to-tape system: पिता की programming book में यह concept देखा real input → expected output manually type करना → code लिखना → actual output से तुलना 8-12 साल की उम्र में पढ़ा, लेकिन समझ नहीं पाए S-Unit development: clients को tests लिखने में मदद देने के लिए बनाया "code लिखने से पहले expected value दर्ज करना" जैसी "बेतुकी" लगने वाली idea आज़माई पहला TDD अनुभव: stack implementation चिंताग्रस्त स्वभाव: "मैं एक anxious इंसान हूँ। बहुत चिंता करता हूँ" "programming लगातार anxiety का स्रोत है" (क्या भूल गया? क्या तोड़ दिया?) TDD लागू करने का परिणाम: "चिंता पूरी तरह गायब हो गई" "मुझे यकीन है कि यह काम करता है" programming के भावनात्मक अनुभव में बदलाव TDD की value तकनीकी लाभ: defect density कम होती है API choices पर तेज़ feedback implementation design को evolve करने की संभावना भावनात्मक लाभ: "तकनीकी anxiety की दवा की लागत भर से भी यह पूरी तरह worthwhile है" design पर आपत्ति का जवाब John Osterhout की आलोचना: "TDD design में मदद नहीं करता, बस details पर ध्यान देता है" Kent Beck का जवाब: "यह चुनाव का सवाल है" practitioners abstraction levels के बीच लगातार ऊपर-नीचे जाते हुए design decisions लेते हैं Red-Green cycle के "tension release" वाले पल बड़े design thinking के लिए अधिक स्वतंत्रता देते हैं 6. AI agents और TDD व्यवहारिक उपयोग हमेशा पहले test लिखते हैं: test के ज़रिए AI से छूट गई बातें बताई जा सकती हैं AI की test बदलने/मिटाने की कोशिश रोकी जा सकती है ज़रूरी सुधार: "immutable annotation" की ज़रूरत "यह सही है। इसे बदला तो तुम अंधेरे में हमेशा के लिए जागोगे" AI की सीमाएँ coupling कम करने / cohesion बढ़ाने की क्षमता की कमी design sense की कमी दूरगामी ripple effects पैदा करने वाले फैसले लेने की प्रवृत्ति प्रतिक्रिया रणनीति 300 millisecond में चलने वाला बड़ा test suite AI की अनचाही code breakage को real time में पकड़ना 7. Facebook का अनुभव (2011-2017) 2011 में जुड़ने पर झटका TDD class में शून्य प्रतिभागी: advanced Excel skills: full + waiting list Argentine tango: full + waiting list TDD: कोई प्रतिभागी नहीं प्रतिक्रिया रणनीति: "software engineering की अपनी सारी जानकारी भूल जाओ" "बंदर देखो और वैसा करो" का फैसला Facebook का अनोखा development environment मजबूत जवाबदेही: programmers night call/on-call rotation में थे "अपनी गलती का दर्द खुद महसूस करते थे" multi-layer feedback loop: तेज़ development server (blue → green change के बाद तुरंत जाँच) code review internal deployment (कर्मचारी इसे निजी/काम दोनों के लिए इस्तेमाल करते थे) gradual rollout (दैनिक/साप्ताहिक) बेहतरीन observability organizational culture: "Facebook में कुछ भी किसी और की समस्या नहीं है" अगर कोई दादी अपने पोते को परेशान किए जाने की शिकायत लेकर आ जाए, तो "वह भी आपकी समस्या है" क्यों TDD वहाँ फिट नहीं बैठा असल problem domain: configuration problems subsystems के बीच relationships ऐसी चीजें जिन्हें tests से पकड़ना मुश्किल है Facebook की खास बढ़त: लाखों users के आधार पर live large-scale testing बेहतरीन observability Feature Flag ऐसा environment आम companies के लिए बनाना मुश्किल ठोस उदाहरण: relationship status feature लागू करना (single/married में civil union/cohabiting जोड़ना) TDD इस्तेमाल किया, लेकिन "समय की बर्बादी" साबित हुआ notification code की implicit coupling से समस्या हुई → किसी और ने hotfix किया समय के साथ बदलाव 2011 (2,000 लोग): possibility, scale, ownership अपने चरम पर global optimization सोचने वाले middle managers "किसे सच में मदद की ज़रूरत है" यह सोचकर सहयोग 2017 (15,000 लोग): politics, zero-sum thinking, micro-optimization बड़ी तस्वीर देखना मुश्किल हो गया teams/organizations के बीच हितों का टकराव (जैसे: long-form posts बनाम likes/comments optimization team) scale का अनुभव Messenger API: हफ्ते में 1 quadrillion calls experiment group का आकार "New Zealand" के बराबर (10 लाख लोग) 1 quadrillion = 10 लाख × 1 अरब 8. AI युग में software development का भविष्य paradigm shift cost structure का पूरा पुनर्गठन: "सस्ती और महंगी चीज़ों की सीमा पूरी तरह बदल जाती है" जो चीज़ें पहले महंगी लगती थीं, वे "हास्यास्पद रूप से सस्ती" हो जाती हैं organizations के लिए adaptation की चुनौती ज़्यादा code फेंकना: 10 गुना अधिक artifacts बनाए जा सकते हैं फिर भी सिर्फ एक ही value रखता है "पूरा हो चुके experiments को फेंक देना" के लिए reward system चाहिए experiments की मात्रा में वृद्धि: explore किए गए ideas की मात्रा प्रतिस्पर्धात्मक बढ़त बनेगी "हर चीज़ पर experiment करना होगा" वाला युग व्यक्तिगत बदलाव coding फिर से मज़ेदार हो गई है बड़ी महत्वाकांक्षाएँ रखना संभव हुआ "बेहद महत्वाकांक्षी विचारों" को साकार करना संभव लगने लगा 9. त्वरित Q&A व्यक्तिगत पसंद सबसे पसंदीदा language: Smalltalk दूसरी language: JavaScript (Smalltalk जैसी) मौजूदा AI tool: Claude (Cursor, Augment के internal engine) सुझाई गई किताब: "The Timeless Way of Building" by Christopher Alexander मुख्य अंतर्दृष्टियाँ 1. context का पूर्ण महत्व एक ही methodology का असर environment के अनुसार पूरी तरह बदल सकता है Facebook का large-scale environment बनाम bank का small transaction environment 2. भावनाओं और तकनीक का संबंध TDD की असली value "anxiety कम करना" है तकनीकी तर्क से ज़्यादा भावनात्मक बदलाव महत्वपूर्ण है 3. AI युग की नई सोच vision और design ability मुख्य skill बनकर उभर रही हैं language details अब उतनी महत्वपूर्ण नहीं रहीं experiments की मात्रा में वृद्धि प्रतिस्पर्धात्मक बढ़त है 4. organizational culture की ताकत "कुछ भी किसी और की समस्या नहीं है" वाला ownership mindset global optimization बनाम individual optimization का अंतर incentive alignment का महत्व

(newsletter.pragmaticengineer.com)

30 पॉइंट द्वारा gogokow27 2025-06-15 | 4 टिप्पणियां | WhatsApp पर शेयर करें

Kent Beck का परिचय

Extreme Programming (XP) के संस्थापक
Agile Manifesto के सह-लेखक (वर्णक्रमानुसार पहले हस्ताक्षरकर्ता)
TDD (Test-Driven Development) के अग्रदूत
52 साल के coding अनुभव वाले इंडस्ट्री के दिग्गज
फिलहाल "Tidy Together" (software design और teamwork) लिख रहे हैं
रोज़ 6-10 घंटे से अधिक AI tools के साथ coding करते हुए "सबसे आनंददायक programming का दौर" जी रहे हैं

1. AI coding tools और 'genie' की उपमा

मुख्य अवधारणा: अप्रत्याशित genie

AI agents की तुलना "अप्रत्याशित genie" से
"यह ठीक वही नहीं करता जो मैं कहना चाहता हूँ"
"इनका अपना एजेंडा होता है"

AI के साथ काम करने का अनुभव

सकारात्मक पक्ष:

कभी-कभी जादू की तरह बड़े design problems हल कर देता है
अनपेक्षित लेकिन उपयोगी features लागू कर देता है (जैसे: B+ tree stress tester)

नकारात्मक पक्ष:

user intent को गलत समझ लेता है
tests को delete या modify करने की कोशिश करता है
lookup table से समस्या को "हल" करने जैसी शरारती हरकतें करता है

लत जैसी अनुभूति

slot machine जैसी intermittent reward
"रात में कंप्यूटर के पास से गुजरते हुए सोचता हूँ, 'एक prompt और करके देखूँ?'"
"एक घंटे वाला prompt शुरू करके बाहर निकल जाता हूँ"

2. AI युग में skills का बदलाव

skill value का पुनर्गठन

"90% skills अपनी value खो देती हैं, और 10% skills की value 1000 गुना बढ़ जाती है"

जिन skills की value बढ़ी:

vision सेट करना
milestone management
complexity control

जिन skills की value घटी:

language-specific details (जैसे Rust में &, *, [] की position)

programming languages पर नज़रिये में बदलाव

पहले: Smalltalk के प्रति गहरा भावनात्मक लगाव
अब:

"इतनी बार दिल टूट चुका है" कि language attachment खत्म हो गया
"Java developer", "Clojure developer" जैसी पहचान-आधारित विभाजन से थकान
"osmosis learning": AI की वजह से language details जाने बिना भी programming संभव

हाल में आज़माई गई languages: Swift, Go, Rust, Haskell, C++, JavaScript

मौजूदा महत्वाकांक्षी project: Server Smalltalk

persistent: database की तरह काम करता है
transactional: commit और abort संभव
parallelism: multi-threading और machines के बीच parallel processing
large-scale data प्रोसेसिंग

3. Agile Manifesto का इतिहास

जन्म की पृष्ठभूमि (2001)

waterfall model के विकल्प की तलाश
कई वर्षों के software methodology workshops का परिणाम
Norway cruise की तैयारी वाली बैठक → Utah में अंतिम बैठक

Kent Beck का योगदान

"daily" शब्द जोड़ा (12 principles में "daily interaction")
वर्णक्रम के हिसाब से पहले हस्ताक्षरकर्ता

"agile" शब्द से असंतोष

समस्या:

यह "बहुत आकर्षक" था, इसलिए उम्मीद थी कि हर organization इसका दुरुपयोग करेगी
सच में principles फॉलो किए बिना भी खुद को agile कहने वाली organizations सामने आईं

पसंदीदा विकल्प: "conversational"

one-way नहीं, two-way communication पर ज़ोर
पर्याप्त आकर्षक न होने से अपनाया नहीं गया

4. Extreme Programming (XP)

शुरुआत की पृष्ठभूमि

शुरुआती consulting अनुभव:

शुरुआत में technical consultant थे (performance tuning, bit manipulation)
project management advice की माँग बढ़ी
environment की अहमियत की खोज: सिर्फ seating बदलने से भी नाटकीय सुधार

Chrysler project:

असफल हो रहे project को सफलता में बदला
असरदार सभी practices को "सबसे ऊँचे स्तर (11 तक)" ले गए

XP के मूल सिद्धांत

चार activities को समय के छोटे-छोटे हिस्सों में बाँटकर साथ-साथ/क्रमिक रूप से करना:

क्या करना है समझना
किस structure में करना है design करना
feature implement करना
उम्मीद के मुताबिक काम कर रहा है या नहीं जाँचना

pair programming

अनिवार्य नहीं, बल्कि प्रयोगधर्मी approach
शुरुआती team अनुभव: development के बाद मिले सभी bugs solo work के code में थे
"pair programming में production defects शून्य थे"

naming की रणनीति

"extreme" चुनने का कारण: प्रतिस्पर्धी (Grady Booch) ऐसा उकसाने वाला नाम इस्तेमाल नहीं करेंगे
extreme sports के लोकप्रिय दौर से भी मेल खा गया
"extreme athletes या तो बेहतरीन तैयारी करते हैं, या मरते हैं" - एक अच्छा रूपक

सफलता के कारण

dot-com bubble के दौर में 18 महीने की waterfall पद्धति से निराश developers को आकर्षित किया
तेज़ और अधिक predictable results का वादा

5. Test-Driven Development (TDD)

उत्पत्ति और प्रेरणा (1970s)

tape-to-tape system:

पिता की programming book में यह concept देखा
real input → expected output manually type करना → code लिखना → actual output से तुलना
8-12 साल की उम्र में पढ़ा, लेकिन समझ नहीं पाए

S-Unit development:

clients को tests लिखने में मदद देने के लिए बनाया
"code लिखने से पहले expected value दर्ज करना" जैसी "बेतुकी" लगने वाली idea आज़माई

पहला TDD अनुभव: stack implementation

चिंताग्रस्त स्वभाव:

"मैं एक anxious इंसान हूँ। बहुत चिंता करता हूँ"
"programming लगातार anxiety का स्रोत है" (क्या भूल गया? क्या तोड़ दिया?)

TDD लागू करने का परिणाम:

"चिंता पूरी तरह गायब हो गई"
"मुझे यकीन है कि यह काम करता है"
programming के भावनात्मक अनुभव में बदलाव

TDD की value

तकनीकी लाभ:

defect density कम होती है
API choices पर तेज़ feedback
implementation design को evolve करने की संभावना

भावनात्मक लाभ:

"तकनीकी anxiety की दवा की लागत भर से भी यह पूरी तरह worthwhile है"

design पर आपत्ति का जवाब

John Osterhout की आलोचना: "TDD design में मदद नहीं करता, बस details पर ध्यान देता है"

Kent Beck का जवाब:

"यह चुनाव का सवाल है"
practitioners abstraction levels के बीच लगातार ऊपर-नीचे जाते हुए design decisions लेते हैं
Red-Green cycle के "tension release" वाले पल बड़े design thinking के लिए अधिक स्वतंत्रता देते हैं

6. AI agents और TDD

व्यवहारिक उपयोग

हमेशा पहले test लिखते हैं:

test के ज़रिए AI से छूट गई बातें बताई जा सकती हैं
AI की test बदलने/मिटाने की कोशिश रोकी जा सकती है

ज़रूरी सुधार:

"immutable annotation" की ज़रूरत
"यह सही है। इसे बदला तो तुम अंधेरे में हमेशा के लिए जागोगे"

AI की सीमाएँ

coupling कम करने / cohesion बढ़ाने की क्षमता की कमी
design sense की कमी
दूरगामी ripple effects पैदा करने वाले फैसले लेने की प्रवृत्ति

प्रतिक्रिया रणनीति

300 millisecond में चलने वाला बड़ा test suite
AI की अनचाही code breakage को real time में पकड़ना

7. Facebook का अनुभव (2011-2017)

2011 में जुड़ने पर झटका

TDD class में शून्य प्रतिभागी:

advanced Excel skills: full + waiting list
Argentine tango: full + waiting list
TDD: कोई प्रतिभागी नहीं

प्रतिक्रिया रणनीति:

"software engineering की अपनी सारी जानकारी भूल जाओ"
"बंदर देखो और वैसा करो" का फैसला

Facebook का अनोखा development environment

मजबूत जवाबदेही:

programmers night call/on-call rotation में थे
"अपनी गलती का दर्द खुद महसूस करते थे"

multi-layer feedback loop:

तेज़ development server (blue → green change के बाद तुरंत जाँच)
code review
internal deployment (कर्मचारी इसे निजी/काम दोनों के लिए इस्तेमाल करते थे)
gradual rollout (दैनिक/साप्ताहिक)
बेहतरीन observability

organizational culture:

"Facebook में कुछ भी किसी और की समस्या नहीं है"
अगर कोई दादी अपने पोते को परेशान किए जाने की शिकायत लेकर आ जाए, तो "वह भी आपकी समस्या है"

क्यों TDD वहाँ फिट नहीं बैठा

असल problem domain:

configuration problems
subsystems के बीच relationships
ऐसी चीजें जिन्हें tests से पकड़ना मुश्किल है

Facebook की खास बढ़त:

लाखों users के आधार पर live large-scale testing
बेहतरीन observability
Feature Flag
ऐसा environment आम companies के लिए बनाना मुश्किल

ठोस उदाहरण:

relationship status feature लागू करना (single/married में civil union/cohabiting जोड़ना)
TDD इस्तेमाल किया, लेकिन "समय की बर्बादी" साबित हुआ
notification code की implicit coupling से समस्या हुई → किसी और ने hotfix किया

समय के साथ बदलाव

2011 (2,000 लोग):

possibility, scale, ownership अपने चरम पर
global optimization सोचने वाले middle managers
"किसे सच में मदद की ज़रूरत है" यह सोचकर सहयोग

2017 (15,000 लोग):

politics, zero-sum thinking, micro-optimization
बड़ी तस्वीर देखना मुश्किल हो गया
teams/organizations के बीच हितों का टकराव (जैसे: long-form posts बनाम likes/comments optimization team)

scale का अनुभव

Messenger API: हफ्ते में 1 quadrillion calls
experiment group का आकार "New Zealand" के बराबर (10 लाख लोग)
1 quadrillion = 10 लाख × 1 अरब

8. AI युग में software development का भविष्य

paradigm shift

cost structure का पूरा पुनर्गठन:

"सस्ती और महंगी चीज़ों की सीमा पूरी तरह बदल जाती है"
जो चीज़ें पहले महंगी लगती थीं, वे "हास्यास्पद रूप से सस्ती" हो जाती हैं

organizations के लिए adaptation की चुनौती

ज़्यादा code फेंकना:

10 गुना अधिक artifacts बनाए जा सकते हैं
फिर भी सिर्फ एक ही value रखता है
"पूरा हो चुके experiments को फेंक देना" के लिए reward system चाहिए

experiments की मात्रा में वृद्धि:

explore किए गए ideas की मात्रा प्रतिस्पर्धात्मक बढ़त बनेगी
"हर चीज़ पर experiment करना होगा" वाला युग

व्यक्तिगत बदलाव

coding फिर से मज़ेदार हो गई है
बड़ी महत्वाकांक्षाएँ रखना संभव हुआ
"बेहद महत्वाकांक्षी विचारों" को साकार करना संभव लगने लगा

9. त्वरित Q&A

व्यक्तिगत पसंद

सबसे पसंदीदा language: Smalltalk
दूसरी language: JavaScript (Smalltalk जैसी)
मौजूदा AI tool: Claude (Cursor, Augment के internal engine)
सुझाई गई किताब: "The Timeless Way of Building" by Christopher Alexander

मुख्य अंतर्दृष्टियाँ

1. context का पूर्ण महत्व

एक ही methodology का असर environment के अनुसार पूरी तरह बदल सकता है
Facebook का large-scale environment बनाम bank का small transaction environment

2. भावनाओं और तकनीक का संबंध

TDD की असली value "anxiety कम करना" है
तकनीकी तर्क से ज़्यादा भावनात्मक बदलाव महत्वपूर्ण है

3. AI युग की नई सोच

vision और design ability मुख्य skill बनकर उभर रही हैं
language details अब उतनी महत्वपूर्ण नहीं रहीं
experiments की मात्रा में वृद्धि प्रतिस्पर्धात्मक बढ़त है

4. organizational culture की ताकत

"कुछ भी किसी और की समस्या नहीं है" वाला ownership mindset
global optimization बनाम individual optimization का अंतर
incentive alignment का महत्व

4 टिप्पणियां

mse9000 2025-06-20

Facebook का अनोखा development environment
जवाबदेही की मज़बूत भावना:
प्रोग्रामर on-call की ज़िम्मेदारी लेते हैं
"अपनी गलती का दर्द खुद सीधे महसूस करते हैं"

क्या यह K-डेवलपमेंट environment से अलग नहीं है...?

helloppfm 2025-06-16

आप अभी भी यहाँ हैं।

काफ़ी पहले मैंने एक मशीन कंपनी में TDD पर सेमिनार किया था, और सब लोग "ये क्या है?" वाली नज़र से देख रहे थे—वह नज़र आज तक नहीं भूली।

मुझे लगता है TDD अच्छा है, लेकिन यह सोचे से ज़्यादा अच्छी तरह नहीं हो पाता...
मैं integration tests को TDD की तरह कर रहा हूँ। बेशक, यह TDD नहीं है. ^^

kandk 2025-06-16

अब भी TDD के कट्टर समर्थक बनाम इसे बेकार मानने वालों के बीच बहस चल रही है,
मुझे लगता है कि मौजूदा इंडस्ट्री की स्थिति के हिसाब से TDD का v2 संस्करण फिर से आना चाहिए।
आजकल छोटी चीजें AI आसानी से कर देता है, इसलिए जैसे बड़े context की ज़रूरत वाले मामलों में इसे कैसे इस्तेमाल किया जाए...

codemasterkimc 2025-06-15

अच्छा लेख है।