30/09/2018, 16:59

Thảo luận Unitest

Mình muốn lập topic thảo luận về unit test điều cần thiết cho mọi lập trình viên . Có bạn nào hứng thú tham gia không?

Tâm Ninja viết 19:06 ngày 30/09/2018

Vậy là đã có một topic lập ra để hỏi về một topic có nên lập hay không… :’(

Thành Phạm viết 19:12 ngày 30/09/2018

Em cũng muốn tìm hiểu unitest, đặt gạch watching hóng…

Nguyễn Minh Dũng viết 19:05 ngày 30/09/2018

Vậy là đã có một topic lập ra để hỏi về một topic có nên lập hay không…

Thực ra topic này phù hợp với dev chat hơn.


@joker muốn nói về unittest chung chung hay trong ngôn ngữ nào nhỉ?

Tâm Ninja viết 19:13 ngày 30/09/2018

Vậy thì anh em hứng thú với TDD, BDD, UnitTest có thể tham gia cùng chúng mình nhé:

facebook.com

CocoDojo

CocoDojo là một sàn luyện Code hoạt động theo hình thức Coding Dojo. Điểm đến của các những người YÊU NGHỀ CODE.

Tom Nguyen viết 19:04 ngày 30/09/2018

Hóa ra là quảng cáo ?

Tâm Ninja viết 19:03 ngày 30/09/2018

Vãi commet không liên quan mà nhiều like thế. Ông kia hỏi về unit test thì tui chỉ cho câu lạc bộ unit test để giao lưu. Là chia sẻ chứ sao lại là quảng cáo. Hội đó có phải do tui tổ chức đâu? - :’( Cảm thấy bị tủn thương…

Nguyễn Minh Dũng viết 19:00 ngày 30/09/2018

Tại OP hỏi một cái xong chạy đâu mất tiêu, chắc đứt cable, nên comment của Tâm làm thay đổi trọng tâm topic mất rồi.

Nguyễn Đình Nghĩa viết 19:05 ngày 30/09/2018

Mọi người có kinh nghiệm gì tại sao nên dùng unit test, unit test tạo thế nào test thế nào. cái này hỏi chung cho mọi ngôn ngữ nhé!

Nguyễn Minh Dũng viết 19:05 ngày 30/09/2018

Vậy phải hỏi là unittest để làm gì mới hợp lý, sau đó mới trả lời được cho các câu hỏi tại sao nên dùng, tạo như thế nào và test như thế nào.

Nguyễn Đình Nghĩa viết 19:01 ngày 30/09/2018

Ok. câu hỏi đầu tiên Unittest để làm gì? Mọi người cho ý kiến.
Ý kiến của mình là kiểm tra xem hàm chạy đúng không?
Câu thứ hai. Hàm private có cần unitest không?
Có người bảo có có người bảo không, theo mình là tùy nhưng nói chung là không cần.

Lập Trình Sư viết 19:08 ngày 30/09/2018

Có 2 tác dụng của Tests và nó ứng với hai trường hợp (Use-case) trong phát triển phần mềm.

  1. Test to Verify
  2. Test to Design

1. Test to Verify (Test Later)

Cái này ứng với mô hình, code xong rồi, thực hiện viết test để kiểm chứng mọi thứ trong code diễn ra đúng như mong muốn.

Mô hình triển khai

  • Waterfall
  • Prototype

Ưu điểm

  • Linh động về thời gian
  • Phần mềm có thể đưa ra sớm.

Nhược điểm

  • Không đảm bảo chất lượng cao của sản phẩm.
  • Tỉ lệ bug cũng cao (ít ra vẫn tốt hơn so với ko làm test)

2. Test to Design (Test First)

Ứng với mô hình TDD, BDD, thực hiện viết test rồi mới viết code. Sử dụng test để thiết kế phần mềm.

Mô hình triển khai

  • Spiral (Agile)

Ưu điểm

  • Đảm bảo sản phẩm đạt chất lượng cực cao, số lượng lỗi giảm triệt để.
  • Lúc phát triển, có vấn đề phát sinh, có thể xử lý kịp thời ngay lập tức.

Nhược điểm

  • Tốn nhiều thời gian và chi phí ban đầu

========================

Hàm private có cần unitest không?

Với hàm private với logic xử lý đơn giản theo nguyên tắc 1-1 thì ko cần test; còn phức tạp thì phải thực hiện Mock.

========================

Có người bảo có có người bảo không, theo mình là tùy nhưng nói chung là không cần.

Việc triển khai Unit Test ở mức độ thế nào, test cái gì, như thế nào gọi là đảm bảo vẹn toàn (Coverage Rate) thì phụ thuộc vào người quyết định chất lượng sản phẩm.

Ở VN, phần lớn do chất lượng lập trình viên thấp, nghe Unit Test như là cái gì đó kinh khủng ghê gớm, nên các coder có tâm lý sợ viết UT.

Chỉ một số ít công ty ở VN thực hiện test khá tốt (chủ yếu là công ty nước ngoài), có thể kể tên đến như là:

  • East Agile (cty của Mỹ vp chính ở SG, mới lập văn phòng tại HN và đang tuyển các tay nghề lập trình viên siêu hạng, tất nhiên là lương cũng khủng rồi .
  • Microsoft : dĩ nhiên làm việc với chính hãng là phải đảm bảo rồi, sử dụng các nền tảng Unit Test Framework của MS.
  • FPT Software: một số đơn vị trong này do yêu cầu của khách hàng nên phải thực hiện đầy đủ quy trình test. Tuy nhiên, UT thì ít thấy chỗ nào làm ổn; ngoại trừ khối làm việc với bên US.

Còn một vài công ty nữa, ko tiện kể tên

Nguyễn Minh Dũng viết 19:00 ngày 30/09/2018

Anh Kim cho một ví dụ về cách thực hiện test first được không?

Tom Nguyen viết 19:10 ngày 30/09/2018

haha sorry nhé. chỉ tội con cá mập

Tom Nguyen viết 19:01 ngày 30/09/2018

Quay lại topic, Unit test đơn giản chỉ là để test từng unit của code/chương trình.
Việc làm unit thực ra chúng ta làm rất thường xuyên, đó là làm xong đoạn nào/hàm nào thì chạy cái, input đầu vào mà chờ đầu ra như vậy là làm unit test rồi. Unit test để khẳng định 1 điều từng đơn vị/hàm của mình chạy đúng. Còn việc nó chạy đúng rồi mà code vẫn không chạy thì là việc của thằng khác, integration test.

Các ngôn ngữ đều hỗ trợ 1 framework nào đó cho việc viết unit test. Ơ viết unit test để làm gì? Vì phía trên mình vừa nói là viết được đoạn nào thì chạy đoạn đó rồi, tại sao phải viết. Vì khi chương trình nhiều chức năng, và không ai chỉ làm xuyên suốt và đơn độc cho 1 dự án cả, nên có nhiều người sẽ tham gia viết code cùng, làm sao để họ verify được function mình viết ra có đúng không nếu không có tài liệu hướng dẫn, comment …

Đã tốn công viết tài liệu thế thì viết luôn unit test ra code đi

  • lưu lại cách test function
  • có thể test tự động (automation test) bằng việt run 1 script nào đó > cho ra kết quả > email thông báo lỗi … nghe thật tuyệt vời.

Tuy nhiên thì tại sao nó không phổ thông, không phải chỉ ở VN đâu mà còn cả ở TG nữa. Vì sao vậy

  • Tốn effort để viết ra unit test
  • Nếu có thay đổi chức năng thì làm thế nào -> tốn effort bảo trì unit test
  • Nếu viết unit test không tốt effort để bảo trì nó cũng là double thảm họa với code

->> tựu chung lại thì chỉ là tốn effort, tốn tiền.

Nhưng lợi điểm nó là gì? là ở việc verify cho integration test.
Những hễ thống quan trọng, hàng triệu người dùng… Nếu deploy sai một chức năng thảm họa sẽ lớn nhường nào, tôi đảm bảo là tôi không biết
Cho nên cần verify ư, nếu theo cách thông thường > 100.000 test cases > test = tay nếu có một thay đổi? >>> ác mộng
Tuy nhiên vẫn còn khá nếu ít thay đổi.
Còn các hệ thống cần có cập nhật thay đổi thường xuyên thì nó thực sự là ác mộng. Lúc này cần nhiều các hệ thống automation test trong đó có unit test.

-> ai dùng và dùng khi nào?

  • Unit test effort > manual test effort >> test = tay cho nhanh
  • integration test tốn nhiều effort >> dùng unit test để giảm chi phí
  • Phát triển bảo trì sản phẩm lâu dài >> dùng unit test để tăng chất lượng + giảm chi phí

Regards,
Manh

Tâm Ninja viết 19:14 ngày 30/09/2018

https://www.facebook.com/events/1419738055012297/
Ai muốn tham khảo về test thì joint nhé. TDD…

scvn viết 18:59 ngày 30/09/2018

Có ai có 1 ví dụ hay 1 project mẫu nào về unit test thì cho mình với. Mình đọc ví dụ về làm unit test app caculation thì hiểu nhưng chưa hiểu viết 1 cái unit test cho những cái này :

  1. Unit test cho 1 function
  2. Unit test cho 1 chức năng theo nghiệp vụ của phần mềm
  3. Unit test cho 1 module.

Mình ví dụ thế này : form login có username, password, nút login và forgot password. Mình muốn viết unit test cho chức năng forgot password thì làm thế nào. (viết unit test cho từng bước của chức năng này)

Chức năng forgot password như sau:

  • Khi bấm nút forgot password thì hiển thị form forgot password, yêu cầu nhập email. Nhập email vào và nhận link verify, bấm vào link verify thì nhảy đến trang nhập password mới. Nhập pass mới bấm OK là hoàn thành.

Vậy viết unit test cho chức năng này như thế nào ?

Cảm ơn các bạn.

Bài liên quan
0