Ở series bài viết trước mình có giới thiệu cho các bạn về Jenkins, 1 công cụ khá là hay ho cho quy trình phát triển phần mềm agile. Tiếp theo series đó, mình sẽ giới thiệu cho các bạn 1 công cụ trong quy trình phát triển agile nữa. Công cụ này là gì thì mĩnh sẽ giới thiệu sau nhé :v Còn trong bài đầu tiên của series mình sẽ tập trung về hướng phát triển phần mềm trong agile. Không biết mọi người đã ai nghe về các loại driven develop chưa nhỉ? Mình tạm thời bây giờ thì có biết qua mấy loại mặc dù chưa áp dụng được cái nào =))
Ai làm agile chắc cái TDD thì nghe là hiểu ấy nhỉ :3 Thôi mình cứ nói lại để cho mọi người cùng nắm được. TDD là chiTDD là mô hình phát triển mà đặt trọng tâm vào việc kiểm thử phần mềm. Chính vì vậy mà phần mềm mà được áp dụng theo TDD đều khá là ít lỗi do tiêu chí của TDD đó là chúng ta sẽ test-firset sau đó là điều chỉnh mã nguồn refactor để đáp ứng testcase  Khi nhận 1 requirement từ khách hàng thì việc đầu tiên của mấy a dev đó là ngồi soạn testcase sau đó mới chạy luôn cho nóng :3 THôi khỏi trình bày thì nó toi là cái chắc. Đó là cái màu đỏ đầu
tiên trong hình :D. Sau đó thì các chàng trai đó sẽ tiến hành sẽ bắt đầu viế code để chạy được chương trình. Yeah ra màu xanh Green (y) ý nghĩa cái hình 2. Ăn mừng cái nào :))
Thành công rồi thì các anh dev của chúng ta sẽ tiến hành làm mịn màng code như Nivea tẩy rửa da mặt. Cái này là Refactor(3) Ủa sao nghe cái này nó cứ ngược ngược với cái mình hay làm hay sao ẩy nhỉ 😕 Mô tả lại cái hình ở trên thì chúng ta có thể tóm gọn lại Red (1): đối với chương trình thay vì nhảy vào viết code chi tiết ngay như mấy con thiêu thân thì chúng ta tạo khung trước ví dụ như chỉ viết tên hàm, tên scripts bỏ qua phần thân Green(2): viết test cho khung đầy đủ Refactor (3): đắp dần đắp dần các đống code vào cái khung đã cos để pass các test ==> Mục đích của việc này có tác dụng đó là sẽ tập trung được vào phân tích yêu cầu và thiết kế chương trình hướng đến người dùng (end-users) hơn là đầu vào, đầu ra (input, output) của tính năng chương trình như mô hình waterfall Việc áp dụng TDD sẽ góp phần làm khoảng cách giữa công việc phát triển và kiểm thử được kéo gần vào nhau, tối ưu quy trình :3 Thế bây giờ mà mấy a dev làm cả nhiệm vụ cảu test thế mấy chị tester đi đâu mất rồi 😐 BDD là gìYên tâm là mấy chị vẫn có việc nhé nhưng bây giờ công việc của các chị cũng có ý nghĩa hơn nhiều (y). Có 1 mô hình mới được đưa ra dựa trên TDD, phải nói là mở rộng của TDD thì đúng hơn đó là BDD (behavior driven develop: phát triển hướng hành vi). Chính vì vậy mà tuy 2 mà 1, tuy 1 mà 2 nhé :* Vai trò của các chị test nhà mình ấy à. Nhiều việc phết đấy nhé: Thay vì có sản phầm hoàn thiện, thì các chị cũng nhảy vào viết mã. Nghe ghê chưa 😀 khác hẳn công việc vẫn làm như viết testcase ra Excel nhé =)). Các mã nguồn này được viết theo hướng ngôn ngữ tự nhiên, y như là văn nói ấy. Đây các bạn xem thử 1 kịch bản test 😀 như 1 bài văn luôn Feature: Some terse yet descriptive text of what is desired In order to realize a named business value As an explicit system actor I want to gain some beneficial outcome which furthers the goal Scenario: Some determinable business situation Given some precondition And some other precondition When some action by the actor And some other action And yet another action Then some testable outcome is achieved And something else we can check happens tooCái kịch bản này được viết dựa trên requirement của hệ thống cũng như hành vi của người dùng tương tác. Với việc phát triển thế này thì các chị test phải giúp các anh dev trong việc giải thích và xây dựng chương trình mang tính thực tiễn với người dùng hơn trước khi bắt tay vào xây dựng chương trình Thế này thì anh dev với chị test ấy à sẽ phải liên hệ mật thiết với nhau để xây dựng code với scripts test theo mô hình TDD. Nghe vẻ tình cảm hẳn ấy nhỉ. BDD có khi lại giúp họ tìm được trái tim nhau =)) Với việc sử dụng BDD, thì kịch bản test sẽ được phân thành 2 cái đó là unittest do mấy chàng dev khỏe khoắn sẽ làm mấy Unit còn các chị test liễu yếu đào tơ thì làm cái to tát hơn đó là feature/acceptance test. HÌnh vẽ bên dưới sẽ thể hiện quy trình áp dụng cho BDD Ai viết BDD?Do BDD đề cao sự cộng tác giữa các thành viên trong dự án cũng như các bên liên quan. Vì vậy, tất cả những người này sẽ xây dựng nên file BDD để đưa ra một cái nhìn chung nhất, chính xác nhất về yêu cầu của dự án. Không mọi người lại nghĩ chỉ có mấy chị test viết thì không đúng đâu nhé Các chị ấy có thể viết trước các feature rồi đưa cho các thành viên trong dự án, các stakeholder để có thể nhận được góp ý, đánh giá xem đã viết thế đúng với yêu cầu của chương trình chưa, viết thế thì hành vi của người dùng đó là đúng hay sai…. So sánh với TDDBDD là cách diễn đạt dễ hiểu hơn TDD, kiểu “lựa lời mà nói cho vừa lòng nhau”. Ở TDD thì nhìn testcase là thấy code (các anh dev lên đỉnh), còn ở BDD thì nhìn thấy testcase là thấy yêu cầu (khách hàng lên đỉnh). Chính vì vạy thì TDD tương đương với cái verification còn BDD tương ứng với specificaiton Nghe hay đấy, thế tôi muốn áp dụng thì thế nào?Hiện tại thì có khá nhiều công cụ hỗ trợ cho việc phát triển theo hướng BDD nhé. Mình liệt kê 1 số thằng cho các bạn RSpec: cho thằng ruby Cucumber: thằng này bắt nguồn từ bên Ruby. Giờ thì có thêm bản cho java 😀 SpecFlow: cháu này được dùng cho thằng C#. Có thể coi nó là Cucumber for .NET Behat + Mink: 2 thằng này thì dùng cho PHP :3 Còn các thằng khác thì mình chả rõ lắm :3 ai biết thì đóng góp thêm nhé CHốtPhần tiếp theo mình sẽ giới thiệu về cách áp dụng BDD cho các kịch bản test nhé. Viết hơn 1000 từ rồi nhọc 😛 |
