นั่งเรียนเรื่อง Introduction to Test and Behavior Driven Development เพราะอยากเพิ่มความรู้เรื่อง TDD กับ BDD ให้กับตัวเอง
หัวข้อที่เรียน เป็นเรื่องเกี่ยวกับการพัฒนาซอฟต์แวร์สมัยใหม่ ที่นำการทดสอบเข้ามาเพื่อให้มั่นใจได้ว่า Code ที่พัฒนาทำงานได้อย่างถูกต้อง
Test Driven Development (TDD) และ Behavior Driven Development (BDD) เป็นสองแนวทางที่ช่วยให้กระบวนการพัฒนาและการทดสอบมีประสิทธิภาพมากยิ่งขึ้น
ความสนุกของหลักสูตรนี้ คือทาง Professor เป็นผู้รู้ในเรื่องที่เกี่ยวกับการ Test เป็นอย่างมาก แม้ว่าชื่อหัวข้อจะเป็น Introduction to Test and Behavior Driven Development แต่พอนั่งเรียนจริงกลับพบว่ามี Assignment ที่ให้ตัวผู้เรียนเขียน Test กันจริงๆ จังๆ ไปจนถึงการสอบ และส่ง Code งาน Test ให้ตรวจกันเลยทีเดียว
Professor สอนตั้งแต่ การวางกรอบของ TDD , BDD และเขียน Test แบบ Inside out > outside in , การเขียน Unit Test เพื่อ Test Function ภายใน , การเขียน Test สำหรับการ Test Database , การเขียน Test สำหรับการ call api การทำ mock data , การทำ Test Coverage , Gherkin syntax , Behavior Driven Development และ Python
มีอยู่ตอนหนึ่งที่ประทับใจ คือในส่วนของ Test Coverage เพราะมีอยู่ครั้งหนึ่งได้รับมอบหมายมาจากหัวหน้าว่า หาก Dev ทำการส่งงานมาให้ตรวจ ให้ทำการตรวจ Unit Test ของเขาด้วยทุกครั้ง ว่ามี Unit Test ทำมาด้วยหรือเปล่า
ตอนนั้นที่รับคำสั่งหัวหน้า ก็เข้าใจว่ามันต้องมีแนบมาส่ง แต่ตัวเองก็ไม่เข้าใจอะไรมากว่า Unit Test มันทำงานยังไง +ต้องมีรูปแบบอย่างไร เพราะสมัยตอนที่ตัวเองเป็น Dev ก็ไม่ได้ทำสิ่งนี้เช่นกัน และเมื่อมาทำงานตำแหน่งนี้ก็ถูกสอนมาว่า Unit Test เป็นเรื่องของ Dev เท่านั้น
กลับมาตอนที่ Dev เอางานมาส่ง Dev ที่ทำงานด้วยก็ Run Unit Test ให้ดูว่ามี Run กี่ Case ผ่านกี่ Case ซึ่งตอนนั้นเราก็ไม่มีความรู้จริงๆจังๆในส่วนนี้ แต่พอเรียนหลักสูตรนี้จบถึงได้รู้ว่า เราจะรู้ได้อย่างไร ว่า unit test ที่ dev ส่งมา มัน cover กับ code ที่เขียนไปแล้วจริงๆ และมันควรจะมี Tools อะไรเพื่อมาชี้ให้เห็นว่า Code ในแต่ละ Function มีตัวไหนบ้าง ที่ไม่ได้รับการ Test ?!
กับอีกตอนหนึ่งคือเรื่องของการปรับความคิดเพื่อที่นำไปเขียน Gherkin syntax ที่แต่ก่อนเคยเห็นตามบอร์ด Jira จะมี Format การเขียนประมาณ As role …, when , then , background พอจบหลักสูตรนี้ ถึงได้เข้าใจว่า “อ่อ นี่เขาเขียนแบบ BDD นี่เอง” ซึ่งหากใครเข้าใจตรงนี้ ก็สามารถนำไปเขียน Code และเขียน Test กันได้อย่างสะดวก
และตอนนี้ก็เริ่มเข้าใจแล้ว ว่าทำไม คนทำ QA ถึงได้ย้ายสายไปเป็น BA , หรือ SA กันต่อได้ง่ายนัก นั่นก็เพราะเขามีความรู้ตรงนี้แข็งแล้วนี่เอง
สรุปเรื่องที่เรียนแต่ละเรื่อง มีหัวข้อประมาณนี้
- การทดสอบช่วยยืนยันว่า Code ที่เราสร้าง ทำงานตามที่คาดหวังหรือไม่
- กระบวนการทดสอบซอฟต์แวร์มี 4 ระดับ: unit, integration, system, และ acceptance
- Test cases เป็นตัวกำหนดการออกแบบโค้ดทั้งใน Behavior Driven Development (BDD) และ Test Driven Development (TDD)
- BDD มุ่งเน้นพฤติกรรมของระบบจากภายนอกสู่ภายใน ขณะที่ TDD มุ่งเน้นการทำงานจากภายในสู่ภายนอก
- Red/Green/Refactor workflow มี 3 ขั้นตอน:
- เขียน unit test ที่ล้มเหลวสำหรับโค้ดที่คุณต้องการให้มี
- เขียนโค้ดพอเพียงเพื่อให้ผ่านการทดสอบ
- ปรับปรุงโค้ด (refactor) เพื่อเพิ่มคุณภาพ
- Nose เป็น Python test runner ที่สามารถเพิ่มสีในผลลัพธ์การทดสอบและเรียกใช้เครื่องมือ code coverage
- Test fixtures ช่วยกำหนดสถานะเริ่มต้นก่อนและหลังการทดสอบแต่ละครั้ง
- Factories และ fakes มีประโยชน์สำหรับการสร้างและจัดการชุดข้อมูลทดสอบขนาดใหญ่
- Patching เป็นเทคนิคในการ mocking ที่นักพัฒนาสามารถเปลี่ยนพฤติกรรมของการเรียกฟังก์ชัน
- Mock objects คือวัตถุที่เลียนแบบพฤติกรรมของวัตถุจริงในลักษณะที่คุณควบคุมได้
- Behavior Driven Development (BDD) เป็นแนวทางการพัฒนาที่เน้นการทดสอบก่อน เพื่อให้แน่ใจว่าแอปพลิเคชันทำงานตามที่คาดหวัง
- ระดับที่เหมาะสมสำหรับการใช้ BDD ในกระบวนการทดสอบซอฟต์แวร์คือการทดสอบ integration, system, และ acceptance
- Workflow ของ BDD มี 3 ขั้นตอน:
- สร้างตัวอย่างหรือสถานการณ์เพื่ออธิบายพฤติกรรมที่ต้องการ
- รันตัวอย่างเหล่านั้นเป็นการทดสอบอัตโนมัติ
- เขียนการทดสอบเพิ่มเติมตามความจำเป็น
- การสร้างสเปค BDD ต้องเขียนฟีเจอร์และเขียนสถานการณ์โดยใช้ไวยากรณ์ Given, When, Then
- Context เป็นตัวแปรที่ถูกส่งเข้าไปในทุกนิยามของขั้นตอน
- การแทนค่าตัวแปร (Variable substitution) ช่วยลดจำนวนขั้นตอนที่จำเป็นและเพิ่มการนำกลับมาใช้ซ้ำ
หลังเรียนจบแล้วรู้สึกขอบคุณทีม IBM และผู้ที่สร้างหลักสูตรนี้ขึ้นมามากๆ เพราะเรียนจบแล้วรู้สึกว่าได้ประโยชน์ และหวังให้ Dev ,QA หรือ BA เองก็ดีได้มาเรียนหลักสูตรนี้กันก่อนได้ไปเริ่มทำงานจริง โดยเฉพาะทีมที่ทำงานเป็น Agile และมี Automated Test…
I’ve been taking a course on Introduction to Test and Behavior Driven Development because I wanted to expand my knowledge on TDD and BDD.
The course focuses on modern software development, incorporating testing to ensure the code works as expected. Test Driven Development (TDD) and Behavior Driven Development (BDD) are two approaches that help improve both development and testing efficiency.
What I found enjoyable about the course is how knowledgeable the professor is about testing. Even though the course is called Introduction to Test and Behavior Driven Development, it turns out that we had real assignments where we had to write tests ourselves. There were actual coding exams where we had to submit our test code for evaluation.
The professor taught everything, from the framework of TDD, BDD, writing tests from the inside out and outside in, creating Unit Tests to test internal functions, testing databases, testing API calls, mocking data, handling Test Coverage, using Gherkin syntax, Behavior Driven Development, and Python.
One part that stood out to me was Test Coverage. In the past, my manager instructed me to check if developers included Unit Tests with their submissions. At that time, I knew it was required but didn’t really understand how Unit Tests worked or what they should look like. When I was a developer, I didn’t do this either, and when I became a QA, I was told that Unit Tests were solely the developer’s responsibility.
Later, when developers showed me their submissions, they ran the tests and showed how many passed or failed. At that time, I didn’t fully understand it. After finishing this course, I finally learned how to know if the Unit Tests provided by developers really cover the code, and what tools should be used to highlight which parts of the code aren’t tested!
Another part I appreciated was learning how to write the Gherkin syntax. I used to see it in Jira boards with formats like “As a role…, when, then, background”. Now, after completing the course, I finally understand that this is BDD in action, and once you understand this, you can write both code and tests much more easily.
I now also understand why many QA professionals transition to BA or SA roles so easily — it’s because they’ve mastered this knowledge.
Here’s a quick summary of what I’ve learned:
- Testing ensures that the code we build works as expected.
- There are four levels of software testing: unit, integration, system, and acceptance.
- Test cases guide the design of the code in both BDD and TDD.
- BDD focuses on the system’s behavior from the outside in, while TDD focuses on how it works from the inside out.
- Red/Green/Refactor workflow in TDD has three steps: write a failing unit test, write enough code to pass it, then refactor the code to improve its quality.
- Nose is a Python test runner that adds color to test results and can call the code coverage tool.
- Test fixtures set up the known state before and after each test.
- Factories and fakes are useful for creating and managing large test datasets.
- Patching is a mocking technique that allows developers to change how a function call behaves.
- Mock objects are objects that mimic the behavior of real ones, with control over how they work.
- BDD ensures that applications behave as intended, using integration, system, and acceptance testing.
- BDD workflow has three steps: create examples/scenarios, run them as automated tests, and write additional tests if needed.
- When writing BDD specifications, we use Given, When, Then syntax.
- Context is a variable passed into each step definition.
- Variable substitution reduces the number of steps needed and maximizes reusability.
After finishing the course, I’m very grateful to the IBM team and everyone involved in creating this course. I feel that it’s truly beneficial and would recommend it to developers, QAs, or BAs to take this course before starting work.