Saladpuk.com
🏆 เนื้อหาหลัก
🏆 เนื้อหาหลัก
  • 💖สลัดผัก
  • 📰มีอะไรใหม่บ้าง
    • 2020
      • 2020-11
      • 2020-10
      • 2020-09
      • 2020-08
      • 2020-03
      • 2020-02
      • 2020-01
    • 2019
      • 2019-12
      • 2019-11
      • 2019-10
      • 2019-09
      • 2019-08
  • 🤔อ่านเรื่องไรดี ?
  • มือใหม่หัดเขียนโค้ด
    • 👶เขียนโค้ดด้วยภาษา C#
      • เกิดมาไม่เคยเขียนโค้ดมาก่อนเบย
      • 👶พื้นฐาน
        • 1.โปรแกรมที่ต้องลง
        • 2.โครงสร้างของโค้ด
        • 3.ชนิดของข้อมูล
        • 4.การสร้างตัวแปร
        • 5.คำสั่งพื้นฐาน
        • 6.การแปลงข้อมูล
        • 7.การเปรียบเทียบค่า
        • 8.การตัดสินใจด้วย IF statements
        • 9.การตัดสินใจด้วย Switch statements
        • 10.การทำงานซ้ำๆด้วย While
        • 11.การทำงานซ้ำๆด้วย Do While
        • 12.การทำงานซ้ำๆด้วย For
        • 13.การแก้โจทย์จากรูป
        • 14.มารู้จักกับ Array กัน
      • 🧑ระดับกลาง
        • 15.Value type vs Reference type
        • 16.ลดงานซ้ำๆด้วย Method
        • 17.มารู้จักกับ Class & Field กัน
        • 18.มารู้จักกับ Constructor กันบ้าง
        • 19.มาเขียน Method ใน Class กัน
        • 20.มารู้จักกับ Property กัน
        • 21.ลองใช้คลาสแบบจริงจังบ้าง
        • 22.การสืบทอด Inheritance
        • 23.Polymorphism
        • 24.Abstract Class
        • 25.Interface
        • 26.Namespace
        • 27.Enum
        • 28.Exception handler
        • 29.ลงลึกกับ string
        • 30.StringBuilder เพื่อนคู่ string
      • 👨⏳ระดับสูง
        • Generic
        • Delegates
        • Action & Func
        • Lambda expression
        • LINQ
        • พระคัมภีร์การใช้คำสั่ง LINQ
      • 💡Tips
        • 💡C# version 8.0
        • 💡Boxing & Unboxing
    • 👶Algorithm
      • 👾Algorithm Big-O
      • 👽Algorithm P & NP
    • 👦OOP
      • 💖Abstraction
      • 💖Encapsulation
      • 🏆Abstraction & Encapsulation
      • 💖Inheritance
      • 💖Polymorphism
      • 🏆Inheritance & Polymorphism
      • 📝ลองเขียน OOP ดูดิ๊
      • 👑OOP + Power of Design
      • 🥰เทคนิคในการออกแบบ
    • 👶บทสรุปฐานข้อมูล
      • เก็บรูปในฐานข้อมูล
      • Database indexing
      • การลบข้อมูล
    • 👦Communication Patterns
    • 👦Design Patterns
      • 🤰Creational Patterns
        • 🏭Factory Method
        • 🏭Abstract Factory
        • ☝️ Singleton Pattern
        • 🏗️ Builder Pattern
        • 🎎Prototype Pattern
      • 🧱Structural Patterns
        • 🔌Adapter Pattern
        • 📪Proxy Pattern
  • Puzzle
    • 🧠Challenges
      • 🐴Google ม้า 25 ตัว
      • 🌉Amazon เสา 2 ต้น
      • 🥇ทองเก๊
      • 💊ยาต้านโควิด
      • 🎩CP หมวก 5 ใบ
      • 🧓Einstein's Riddle 01
  • พื้นฐานที่ควรต้องรู้
    • 🐳Docker
      • 📦Docker Containers
      • 🃏Docker Exercise 01
      • 🛠️ Docker Tools
      • 🗃️ Docker Registry
      • 🖼️ Container Image
      • 📢Docker Push
      • 🔄WSL
    • 👶Clean Code
      • 🧓Uncle Bob - Clean Code
      • 🧓Uncle Bob - Comments
      • 🧓Uncle Bob - Naming
      • 🧓Uncle Bob - Mindset
      • 🧓Uncle Bob - TDD
    • 👶Code Smells
    • 👶สิ่งที่คนเขียนโค้ดมักเข้าใจผิด
    • 👶AI พื้นฐาน
    • 👶Git พื้นฐาน
      • Git branching strategy
    • 👶Cloud พื้นฐาน
    • 👶UML พื้นฐาน
      • Activity Diagram
      • Class Diagram
      • Sequence Diagram
      • Use case Diagram
      • บทสรุปการใช้ UML
    • 👶Data Scientist
      • การเลือก Algorithms ให้ AI (1/5)
      • การเตรียมข้อมูลให้ AI (2/5)
      • หลักการตั้งคำถามให้ AI (3/5)
      • แฉความลับของ AI Model (4/5)
      • หัดเขียน AI จาก AI ของคนอื่น (5/5)
    • 👶DevOps พื้นฐาน
    • 👶Docker ขั้นพื้นฐาน
      • Image and Container
      • แชร์ Docker Image ที่สร้างไว้
    • 👶Microservices พื้นฐาน
      • Microservices ที่ดีมีลักษณะยังไง
      • Microservices Tips
      • จาก Monolith สู่ Microservices
    • 👶ความรู้พื้นฐานในการทำเว็บ
    • 👦Bottlenecks of Software
      • หัวใจที่สำคัญที่สุดของฐานข้อมูล
    • 👦Agile Methodology
      • Agile in a Nutshell
      • Software Development Life Cycle
      • Code Review
    • 👦Security พื้นฐาน
      • การเก็บรหัสผ่านที่ถูกต้อง
      • Security in actions
        • Hash function
      • Security Principles
      • 😎The Matrix 1
      • 😎The Matrix 2
      • HTTPS in a nutshell
    • 👦SOLID Design Principles
      • มารู้จักกับ SOLID กันดีกว่า
      • Single-Responsibility Principle
      • Open/Closed Principle
      • Liskov Substitution Principle
      • Interface Segregation Principle
      • Dependency-Inversion Principle
  • Cloud Computing
    • 👶Microsoft Azure 101
      • สมัคร Microsoft Azure
      • รู้จักกับ Resource Groups
      • สร้างเว็บตัวแรกกัน
      • สร้าง Virtual Machine กัน
      • ประเภทของคลาว์เซอร์วิส
      • มาสร้าง Logic App กัน
      • มาสร้าง Function App กัน
      • คลาว์คิดเงินยังไง ?
      • Cloud Native
      • Guideline for Cloud scaling
      • Auto Scaling
    • 👶Azure App Services
    • 👶App Service Plan
    • 👶Azure Storage
      • Blob storage
        • ลองสร้างที่เก็บไฟล์กันเลย
        • เข้าใจ Blob storage ให้มากขึ้น
        • ลองเขียนโค้ดอัพโหลดไฟล์กันบ้าง
        • สร้างเว็บจากที่ฝากไฟล์บนคลาว์
    • 👶Azure Bot Service
      • Bot เข้าใจเราได้ยังไงกันนะ
    • 👶Azure Cognitive Services
      • การสร้าง Cognitive Services
      • การ Login ด้วยใบหน้า
      • อ่านลายมือจากรูปเป็นตัวอักษร (OCR)
      • เขียน AI แยกของต่างๆทำยังไง?
      • เขียนแอพ ทายอายุ บอกเพศ ง่ายจิ๊ดเดียว
      • เขียนแอพให้ AI อธิบายรูปเป็นภาษาคน
    • 👶Machine Learning Studio
      • มาสร้าง AI ของแท้ตัวแรกของเรากัน
      • สร้าง AI ตัดสินใจอนุมัติบัตรเครดิต 💳
      • ลองเรียกใช้ AI ของเรากัน
    • 👶Azure Service Fabric
      • สร้าง Service Fabric กัน
    • 👶Blockchain
      • Blockchain ทำงานยังไง ?
      • Consensus Algorithm คืออะไร ?
      • สร้าง Blockchain ใช้เองกัน !
      • หัดเขียน Smart Contract กัน
    • 👶Power BI
    • 👶Azure Web App
      • เซิฟเวอร์บนคลาว์ ราคา? ต่าง?
    • 👶Azure DevOps
      • เล่น Azure DevOps กัน
      • เล่นกับ Repository
      • ลองทำ Continuous Integration (CI)
      • ลองทำ Continuous Delivery (CD)
      • เล่น Kanban Board
    • 🤠Cloud Playground
      • การป้องกันความลับหลุดตอนที่ 1
      • การป้องกันความลับหลุดตอนที่ 2
      • การป้องกันความลับหลุดตอนที่ 3
      • การป้องกันความลับหลุดตอนจบ
  • Software Testing
    • 👦Test-First Design
    • 👦Test-Driven Development
      • 1.มารู้จักกับ TDD กันดีกว่า
      • 2.Test cases เขาเขียนกันยังไงนะ
      • 3.เครื่องมือในการทดสอบ
      • 4.การใช้ Theory และ InlineData
      • 5.โค้ดที่ทดสอบได้
      • 6.Mantra of TDD
      • 7.Functional & None-Functional testing
      • 8.Manual vs Automation testing
      • 9.Automation Frameworks in .NET
      • 10.Mock Framework
      • 11.มาเรียนการใช้ Moq กันเถอะ
      • 12.สรุป
  • Web
    • 👦Web API
      • 1.Web API คืออะไร
      • 2.ติดตั้ง .NET Core SDK
      • 3.สร้าง Web API ตัวแรกกัน
      • 4.Verbs
      • 5.Swagger เพื่อคู่ API
      • 6.การใช้ Model
      • 7.เรียก Web API ผ่าน Postman
      • 8.มาจัดกลุ่ม API กัน (1/2)
      • 9.มาจัดกลุ่ม API กัน (2/2)
  • Software Design
    • 🤴Design Patterns
      • 🦈Creational patterns
        • Abstract Factory
        • Builder
        • Factory Method
        • Prototype
        • Singleton
      • 🦈Structural patterns
        • Adapter
        • Bridge
        • Decorator
        • Facade
        • Proxy
      • 🦈Behavioral patterns
        • Chain of Responsibility
        • Command
        • Iterator
        • Mediator
        • Memento
        • Observer
        • State
        • Strategy
        • Template Method
        • Visitor
Powered by GitBook
On this page
  • 🧓 เกริ่น
  • 💖 หัวใจการทำเทส
  • 🎯 กฏเหล็ก
  • 💡 หลักในการออกแบบ
  • 🙌 ส่งท้ายบท
  • 🎥 วีดีโอลุงบ๊อบ

Was this helpful?

Export as PDF
  1. พื้นฐานที่ควรต้องรู้
  2. Clean Code

Uncle Bob - TDD

🤔 เขียนเทสมันจะช่วยให้การออกแบบมันดีขึ้นได้ไง ?

PreviousUncle Bob - MindsetNextCode Smells

Last updated 4 years ago

Was this helpful?

การทำ Clean Code ตอนที่ 4 จากวีดีโอของ 🧓 ลุงบ๊อบ หรือ หนึ่งในมหาเทพวงการคอมพิวเตอร์ ซึ่งในรอบนี้เราจะมาดูกันว่า การทำเทสมันช่วยเรื่องการออกแบบได้ไง หลายคนเคยทำเทสแล้วพบว่ามันช้าเสียเวลามาก ดังนั้นบทความนี้จะมาเฉลยกันว่าจริงๆแล้วมันดีหรือไม่ดีกันแน่นะ ?

วีดีโอตัวนี้หลักๆลุงบ๊อบแกมานั่งทำ TDD ให้ดู ซึ่งแมวน้ำเคยทำวีดีโอ กับ เขียนบทความเรื่องพวกนี้ไว้เยอะและ ดังนั้นขอข้ามตัวอย่าง เขียนแต่สรุปประเด็นให้อ่านแทนนะ ส่วนใครอยากดูที่แมวน้ำทำไว้ก็ศึกษาต่อได้จากลิงค์นี้เบย กับ

แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของบทคอร์ส หากเพื่อนๆแมวน้ำสนใจศึกษาเรียนรู้ว่าการทำ Clean Code ว่ามันคืออะไร? มีอะไรบ้าง? บลาๆ ก็สามารถกดที่ชื่อบทความสีฟ้าๆเข้าไปอ่านได้เลยครัช

🧓 เกริ่น

โปรแกรมเมอร์ส่วนใหญ่จะ ไม่กล้าแก้โค้ดเพราะกลัวว่าที่แก้ไปมันจะไปทำให้จุดอื่นๆพัง ซึ่งหมายความว่าเราจะทำคลีนโค้ดได้ยากขึ้น เพราะแม้จะเห็นจุดที่โค้ดพันกันวุ่นวาย ก็จะไม่มีคนกล้าไปแตะโค้ดเหล่านั่นนั่นเอง แต่ในทางตรงข้าม ถ้าเราเขียนเทสไว้แล้วเราแก้โค้ดปุ๊ปแล้วมันพังปั๊ป เราก็จะรู้ได้ทันทีว่าที่แก้ไปมีปัญหานะ ดังนั้นการทำเทสนั้นจะช่วยให้เราแก้โค้ดได้เรื่อยๆโดยไม่กลัว bug นั่นเอง

🧓 เมื่อเราสามารถแก้โค้ดได้โดยไม่ต้องกลัวว่ามันจะมี bug นั่นหมายความว่า เราก็จะสามารถ ปรับ Design เปลี่ยน Algorithm ได้ตลอดเวลา และรวมถึงเมื่อมี Requirement ใหม่ๆเข้ามา เราก็จะทำมันได้โดยที่รู้ว่ามันไม่ไปทำให้สิ่งที่ทำงานได้อยู่แล้วพังนั่นเอง

เทสในวงการซอฟต์แวร์มีหลายระดับ ซึ่งระดับแรกที่ต้องรู้จักคือ (TDD) Test-Driven Development ซึ่งมันมีหัวใจหลักคือ 💖 ช่วยในการออกแบบโครงสร้าง เลยทีเดียว ดังนั้นเราจะมารู้จักเนื้อแท้มันดีกว่าว่ามีค่าพอจะเสียเวลาชีวิตเราไหม?

แนะนำให้อ่าน หากใครสนใจอยากรู้ว่าการทำ TDD หรือ Test-Driven Development จริงๆแล้วต้องทำยังไงบ้างสามารถดูตั้งแต่เริ่มต้นจนจบได้จากลิงค์นี้ ซึ่งแมวน้ำได้อธิบายเทสตั้งแต่พื้นฐานไว้อยู่แล้ว และเทียบให้ดูระหว่างทำกับไม่ทำในระยะยาวมันต่างกันขนาดไหนเรียบร้อยละ ส่วนใครขี้เกียจดูซีรี่ยาวๆก็อ่านบทความสั้นๆเพื่อให้พอเห็นภาพได้จากลิงค์นี้ครับ

💖 หัวใจการทำเทส

🧓 การเขียนเทสมันเป็นวินัยของโปรแกรมเมอร์ โดยมันออกมาเองแบบไม่มีคนบังคับ เพราะรู้ว่าถ้าไม่ทำมันผลเสียอะไรจะตามมา เหมือนกับ หมอล้างมือก่อนตรวจเสมอ ซึ่งหมอไม่ได้โดนบังคับให้ล้างมือ แต่หมอทำเพราะเขารู้ว่าจะเกิดผลเสียตามมาเยอะกว่าการไม่ล้างขนาดไหนนั่นเอง

🧓 เทสจะช่วยให้เรา Design ได้ดีขึ้น โดยช่วยให้เราสร้างแต่ของที่จำเป็นเท่านั้นออกมา ดังนั้นเราจะสามารถ Refactor design ได้ง่าย เพราะโค้ดที่ได้มามันไม่ค่อยไปวุ่นวายกับโค้ดอื่นๆนั่นเอง ตามชื่อมัน Driven Design

🎯 กฏเหล็ก

เมื่อเราจะเริ่มเขียนโค้ดตาม requirement ที่ได้รับมานั้น ถ้าเราทำ TDD มันมีกฎง่ายๆอยู่คือตามนี้

  1. ห้ามเขียนโค้ดจนกว่าจะเขียนเทส - เดฟหลายคนพอจับคอมปุ๊ปก็จะเขียนโค้ดเลย ซึ่งข้อเสียคือ เรารู้ได้ไงว่าเราเข้าใจตัว requirement นั้นจริงๆ? หรือ เรารู้ได้ไงว่ามันควรจะต้องสร้างคลาสใหม่ หรือต้องมี method นั้นจริงๆ? ดังนั้นเราจะต้องเขียนเทสเพื่อพิสูจน์ว่าสิ่งที่เราคิดมันถูกต้องนั่นเอง

  2. ห้ามเขียนเทสต่อจนกว่าจะทำให้เทสตะกี้ผ่าน - หลังจากที่ทำข้อแรกเสร็จเราจะได้ ตัวที่เอาไว้ทดสอบโค้ดเรา 1 ตัวละ ดังนั้นเราก็จะเริ่มเขียนโค้ดให้ตัวทดสอบตัวนั้นผ่าน เพื่อเป็นการพิสูจน์ว่า การเพิ่มคลาสนี้ ใช้ตัวแปรนั้นๆ สามารถทำให้ได้ผลลัพท์แบบที่เราอยากได้นั่นเอง

  3. กลับไปทำข้อ 1 ใหม่ โดยเพิ่มเทสให้ครบทุกกรณีที่มันจะเกิดขึ้นได้ เพื่อเป็นการพิสูจน์ว่าโค้ดของเราทำงานได้กับทุกรูปแบบที่มันเป็นไปได้ โดยไม่มีข้อผิดพลาดนั่นเอง

🧓 หลายคนจะเขียนเทสหลังจากที่โค้ดทุกอย่างทำงานได้แล้ว ซึ่งก็จะพบว่า มันเทสยาก เพราะตัวโครงสร้างไม่ได้ถูกออกแบบให้เทสได้ตั้งแต่ต้น ดังนั้นเราก็ต้องไปแก้โค้ดให้มันเทสได้ ซึ่งคำถามคือ เราจะรู้ได้ไงว่าโค้ดที่เราแก้ไม่ทำให้เกิด bug? ดังนั้นจงเขียนเทสก่อนเขียนโค้ดซะ

🧓 โปรแกรมเมอร์ส่วนใหญ่จะมีปัญหากับแนวคิดแบบนี้ เพราะของบางอย่างที่ง่ายๆตรงไปตรงมา ทำไมไม่เขียนโค้ดไปเลย ซึ่งคำตอบถ้ามองแบบผิวเผินก็จะเป็นแบบนั้นแหละ แต่ถ้าเรามองในระยะยาว การเขียนเทสมันถูกทดสอบมาแล้วว่ามันจะทำให้เราทำงานได้เร็วขึ้นจนแบบที่ไม่เขียนเทสตามไม่ทันเลยทีเดียว (ปล.ต้องเขียนเทสให้เป็นด้วยนะ)

ข้อควรระวัง เดฟหลายๆคนเวลาเจอ bug ก็จะไปนั่งหา bug โดยการใช้ Debugging แล้ววาง break point ตามจุดต่างๆชิมิ ขอบอกเลยว่า พยายามเลิกใช้ Debugging tools เหล่านั้นได้แล้ว เพราะกระบวนการ debug เป็นของที่เสียเวลา และมันอาจจะแก้ปัญหาจุดนั้นๆได้ แต่ไม่มีอะไรการันตีได้เลยว่า คุณแก้ bug ได้หมดจริงๆ ซึ่งต่างจากการมี test case เพราะมันเร็วกว่าและช่วยเช็คให้เราได้ว่าของที่แก้มันไม่ทำให้อย่างอื่นพัง

หากใครเคยได้ทำงานที่มี security สูงมากๆจริงๆจะพบว่า เราไปยุ่งกับ Production ไม่ได้เลย ต่อ database ตรงไม่ได้ เข้า server ก็ไม่ได้ เพราะมันเป็น Environment ปิด (หากมีคนในทีมเข้าไปแก้อะไรมั่วๆได้อาจะทำให้เกิดการโกงได้แบบง่ายๆเลย) ดังนั้นถ้าบริษัทคุณแข็งในด้าน Sensitive data จริงๆ เราจะ debug ไม่ได้เลย และต้องพึ่งการทำ Mornitoring เท่านั้น และแนวโน้มสมัยนี้ผลักให้เราไปทำงานบนคลาว์มากขึ้น ดังนั้น Tracking system คือของที่จะมาลดบทบาทของ Debugging นั่นเอง

เกร็ดความรู้ 1 GUI จริงๆก็สามารถเขียนเทสได้นะ เช่น ทดสอบว่าหน้า Login ทำงานถูกหรือเปล่า เขาก็จะมี test case สำหรับตรวจสอบเป็นขั้นๆเลย เช่น เมื่อเข้ามาให้กรอก username กับ password เป็นแบบนี้ แล้วสั่งให้กดปุ่ม login มันจะต้องเข้าสู่ระบบได้ บลาๆ ซึ่งนี่ก็เป็น test อีกรูปแบบหนึ่งเหมือนกัน แต่ไม่ได้หมายความว่าเราจะไม่ทำ Manual Test แล้ว เพราะการเขียนเทสมันไม่สามารถตอบเรื่องความสวยงามได้ เช่น หน้า Login แบบนี้สวยหรือยัง ตำแหน่งเหมาะสมหรือเปล่า ควรจะใช้ตัวอักษรเล็กลงดีไหม บลาๆ ดังนั้นการเอาคนมาตรวจก็ยังจำเป็นอยู่นั่นเอง

เกร็ดความรู้ 2 เราสามารถนำ Pair Programming มาช่วยกันเขียน TDD ได้นะ ซึ่งปรกติเราจะสลับตากัน โดยให้คนแรกเขียนเทส fail แล้วให้คนที่สองทำให้เทสผ่าน แล้วก็สลับมาเป็นคนที่สองเขียนเทส ให้คนแรกเขียนโค้ดให้ผ่าน สลับไปสลับมาแบบนี้เรื่อยๆ มันจะช่วยให้แต่ละคนอุดจุดบอกที่อีกฝั่งตกได้ และยังช่วยเสริมความเข้าใจในตัวงานได้ดียิ่งขึ้นด้วย

💡 หลักในการออกแบบ

ในการเขียนเทสนั้นมีของ 2 อย่างที่มันเกี่ยวข้องกันนั่นคือ โค้ดสำหรับเทส กับ โค้ดที่ทำงานจริง ซึ่งของพวกนี้มันมีวิธีการคิดที่ต่างกันคนละมุมคือ

  • โค้ดสำหรับเทส - จะต้องมองในมุมของการเทส นั่นหมายความว่า ทุกครั้งที่เพิ่มเคสใหม่ๆเข้าไป มันจะ ระบุเจาะจงมากขึ้นไปเรื่อยๆ และเริ่มแตกเป็นหลายๆกรณีลึกเข้าไปเรื่อยๆจนถึงเคสขอบ (เคสที่มีโอกาสเกิดน้อยมาก หรืออาจจะไม่เกิดเลย แต่เราต้องทำเพราะถ้ามันเกิดขึ้น อย่างน้อยโค้ดของเราก็จะไม่พัง)

  • โค้ดที่ทำงานจริง - จะต้องมองในมุมของระบบที่จะทำงานด้วยกัน ดังนั้นทุกๆครั้งที่เพิ่มโค้ดที่จะเอาไปใช้งานจริงๆ เราจะต้องทำให้มันทำงานได้แบบกว้างๆ (Generalize) มากขึ้น ห้ามทำให้มันไปยึดติดกับของบางสิ่งบางอย่าง เพราะไม่อย่างนั้นเวลาที่ต้องแก้ไขจะทำได้ยากนั่นเอง

🧓 เดฟหลายคนจะมีปัญหาในการเอา TDD ไปใช้ เพราะทั้ง 2 เรื่องนี้มันคิดสวนทางกันเลย ยิ่งเพิ่มยิ่งเจาะจง กับ ยิ่งเพิ่มยิ่งไม่เจาะจง ซึ่งจริงๆก็ไม่เกี่ยวกับ TDD โดยตรง แต่มันเป็นหลักในการออกแบบขั้นพื้นฐานนั่นเอง

🙌 ส่งท้ายบท

🧓 หากใครเอา TDD ไปใช้แล้วคิดว่ามันช้า ลุงบ๊อบบอกเลยว่าเพราะ คุณ(เอ็ง)ยังกากอยู่ ยังฝึกไม่ชำนาญพอ เพราะถ้าทำจริงๆสุดท้ายมันจะเร็วจนไม่มีโปรเจคไหนที่เราจะไม่ทำเทสเลย แต่ห้ามไปฝึก TDD ในโปรเจคที่จะใช้จริงนะไม่งั้นบรรลัยจะบังเกิด ให้หาเวลาว่างไปฝึกกับปัญหาอะไรก็ได้เรื่อยๆจนกว่าจะเข้าใจถึงแก่นมันจริงๆจะดีกว่า

🎥 วีดีโอลุงบ๊อบ

ตัวเทสที่ได้มามันคือ Document ของระบบ หากเราใช้หลักการของ (SbE) Specification by Example เข้ามาช่วย เราก็ไม่จำเป็นต้องมีคนมาเขียน document อีกเลย เพราะงานที่เดฟทำมันเป็น selfdocument ในตัวอยู่แล้ว แถมใครอ่านก็เข้าใจ ไม่ต้องมีความรู้ในเรื่องการเขียนโค้ดเลยก็ยังได้ เดี๋ยวแมวน้ำจะเขียนตัวอย่างการทำ SbE อยู่ติดตามได้จาก นี้เด้อ

แนะนำให้อ่าน ทำไมโค้ดที่ทำงานจริงถึงห้ามเขียนเฉพาะเจาะจง แมวน้ำเคยอธิบายไว้ในบทความ แล้ว ซึ่งมันเป็นหัวใจหลักของการทำ Architecture Design เลย

TDD เป็นแค่ส่วนหนึ่งของการทำเทส ถ้าเราศึกษาต่อจะพบว่าการเขียนเทสนั้นมีหลายมิติมาก และแต่ละเรื่องมันก็จะเทสเฉพาะส่วนของมันเท่านั้น และวิธีทำก็เป็นคนละเรื่องกันนั่นเอง หากใครสนใจก็ลองไปศึกษาต่อได้กับ

🧓 สมัยก่อนลุงบ๊อบก็คิดว่าแนวคิดแบบ TDD มันงี่เง่ามาก ไอ้บ้าที่ไหนจะเขียนเทสก่อนเขียนโค้ดจริง จนกระทั่งแกได้ไปนั่งทำ Pair Programming กับ (หนึ่งในมหาเทพอีกองค์) ถึงได้เข้าใจว่ามันเป็นเทคนิคที่ทรงพลังจริงๆ

👶
🧓
Robert C. Martin
👦 Test-Driven Development
👦 Test-First Design
👶 Clean Code
👦 Test-Driven Development
👦 Test-First Design
Specification by Example
เพจแมวน้ำ
🤰 Creational Patterns
Software Testing
Kent Beck