 |
| http://www.filecatalyst.com/wp-content/uploads/tdd.png |
Test Driven Development (TDD) là một trong rất nhiều quy trình phát triển phần mềm (không chỉ trong lĩnh vực web). Đây là một quy trình phát triển sản phẩm dựa trên test.
KHÔNG BÀN LUẬN
Bài viết này không nhằm giải thích thế nào là TDD, không phân tích ưu nhược điểm TDD, không so sánh TDD với các quy trình khác, và càng không hướng dẫn mọi người cách thực hiện TDD. Nếu bạn đang tìm một trong những thứ mình vừa đề cập bên trên, bạn có thể ngừng đọc tiếp phần bên dưới ^_^VẬY BÀN ĐIỀU GÌ - NOTHING ^_*
Bài viết cũng chẳng bàn thêm gì trong TDD, chỉ là chia sẻ góc nhìn của mình khi dấn thân làm TDD, những cảm nhận, suy nghĩ, khó khăn và những thú vị xung quanh TDD mà mình từng trải nghiệm.Nếu tới đây rồi mà bạn vẫn còn đọc tiếp thì có lẽ bài viết có phần nào khiến bạn hứng thú. Và giờ thì chúng ta vào chủ đề chính của bài viết.
Điều gì khiến mình bắt đầu tìm hiểu TDD và code tests
Trước đây hơn 2 năm, mình không hề biết gì là TDD cũng như code tests. Mình code xong, mở browser lên bấm mà chạy là xem như mình là đúng (và đây cũng là hành vi của đa số developer) chuyện testing thì cứ giao cho bộ phận QC đảm nhận. Do cty mình làm luôn có bộ phận này nên mình rất thoải mái code và deploy, bug hay error thì có QC lo rồi ^^Khi mình bắt đầu học qua Zend Framework 2, nơi mà có thể share nhau những module tự viết và tự học lẫn nhau. Và cũng như những developer ZF2 khác, mình cũng có một module và public lên cho cộng đồng ZF2. Tuy nhiên, câu đầu tiên mà mình nhận được khi nhờ công đồng này review, support đó là "testsssssssss"
Và như trao đổi, họ chỉ review giúp khi mình có bộ tests. Thế là từ mong muốn đc review code mình đã học cách viết test.
Từ khó khăn đến trở thành con nghiện
Dấn thân vào con đường này với mình phải nói là khó khăn vô cùng. Việc đầu tiên đó đi tìm mấy bài tutorial học cách mà học viết test. Nhưng đâu có cái gì mà trơn tru và hoàn hảo. Vấp phải rất nhiều thứ không thuận lợi. Đặc biệt là xung quanh mình hầu như chẳng ai đụng chạm tới cái vấn đề này, càng khiến mình bị lung lay với câu hỏi: "Tại sao phải viết test? Nó giúp mình được gì?..."Mình chẳng biết code test ra làm sao cho đến 1 ngày, mình đọc được một bài viết giúp mình hiểu rõ hơn thế nào là UNIT. Thế là từ đó mình cải tiến được nhiều thứ, không chỉ trong test mà cả trong code.
Sau đó mình cũng tự trả lời được cho chính mình những câu hỏi trên.
- Để tránh những lỗi lặt vặt mà mình cứ đinh ninh là chắc chắn làm đúng (sai chính tả, sai key trong array, quên return trong 1 function ...). Đôi khi những điều này cũng sẽ giải quyết đc khi bạn đụng tới nhưng cái vấn đề là khi nào mới đụng ^_^
- Là một document tốt nhất cho developer. Theo quan điểm cá nhân mình, mình thích đọc code hơn là đọc 1 tài liệu mô tả cách thức chạy code. Cứ quăng cho mình một đoạn code sample, mình đọc chắc nhanh hơn đoạn mô tả document ^_^
- Khiến mình code phải suy nghĩ kỹ hơn, chặt chẽ hơn và nhất quán hơn. Vì khi code ra thì mình phải nghĩ tới việc test nó thế nào
Thế giới quanh ta và sự thật đáng buồn
Thật ra thì mình cũng đi nói chuyện nhiều với nhiều người, phỏng vấn ở 1 vài công ty, và họ đều không quan tâm lắm đến chuyện code test. Và có bạn còn cho rằng mở browser lên bấm bấm vài cái chính là UNIT TEST. Nên mình chưa tìm thấy nên nào ở Việt Nam (tính đến thời điểm hiện tại) là cần thiết cái này lắm. Nhưng cũng không sao, mỗi người mỗi quan điểm mới là xã hội được. Học thêm 1 kỹ năng vẫn tốt hơn là thiếu đi 1 cái mà ^_^Chốt
Những chia sẻ trên tất cả đều mang tính cá nhân, bạn nào không thích thì comment nhỏ nhẹ chớ la ó, bức xúc làm gì. Xem xong thấy không được gì cả thì bỏ qua luôn cũng được. Mình cũng đã nói, mình code test là cho mình chứ cũng không ảnh hưởng đến ai. Mình cũng đã triển khai tốt 1 code test cho dự án Phalex |
| http://tmquang6805.github.io/phalex/ |
TDD và quan điểm của tôi
ReplyDeleteTest Driven Development (TDD) là một trong rất nhiều quy trình phát triển phần mềm (không chỉ trong lĩnh vực web). Đây là một quy trình phát triển sản phẩm dựa trên test.