thắc mắc Các bác viết unit test thế nào ạ.

Donald Trump USA_No1 đã nói:

E k viết UT bh nhưng mà có principle viết UT là không động đến db thật, ut chỉ viết trên logic code bác ạ

Nhấp để mở rộng...

1. controllers (mock services)
2. services (mock data access)
3. data access (mock database)
4. database (viết test bằng SQL scripts để verify, stored procedure tests...)

1. controllers (mock services)
2. services (dek mock gì cả test thẳng từ services xuống database luôn). Các thím gọi nó là unit test hay integration test cũng được, ko quan tâm.

Pepe.The.Frog đã nói:

Thế mục đích viết UT để làm gì? Để đảm bảo code chạy đúng khi lên production đúng ko?

90% logic nó nằm trong stored procedure rồi thì mock database để viết UT trên service làm cái gì trong khi tốn effort cho nó lại vô ích.

Máy móc thế

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

Mô hình thường thấy trong các project hiện tại thì có 4 tầng như này:

1. MVC, MVVM tuỳ web hay desktop apps
2. Services
3. Data Access (ORM hoặc Repositories)
4. Database (stored procedures, triggers...)

Nếu viết unit tests kỹ thì 1 feature mới phải viết test cho cả 4 tầng này.

Tầng 1 là MVC, MVVM thì có thể viết UT cho controllers, viewmodels.. cái này ko có gì bàn cãi, cứ mock thằng services rồi viết thôi.

Các tầng 2, 3, 4 thì thật sự logic nặng nhất ở tầng 3 và 4. Services đa phần chỉ là gọi thằng 3 và 4 lên thôi. Hiếm lắm mới có cái services gọi nhiều repository hoặc gọi services khác với logic if else phức tạp. Trong khi đó cái tầng 3, 4 thì câu SQL query thường phức tạp hơn rất nhiều.

Giờ có 2 hướng chọn viết UT:
Cách 1. Viết unit test cho cả 4 tầng:

1. controllers (mock services)
2. services (mock data access)
3. data access (mock database)
4. database (viết test bằng SQL scripts để verify, stored procedure tests...)

Cách 2: Viết test cho 2 chổ:

1. controllers (mock services)
2. services (dek mock gì cả test thẳng từ services xuống database luôn). Các thím gọi nó là unit test hay integration test cũng được, ko quan tâm.

Tôi chọn cách 2 vì trong project thực tế, deadline dí liên tục thì có sh*t mà đủ time để viết test cho cả 4 tầng như cách 1. Hơn nữa cách 1 muốn đảm bảo test đúng thì phải test đủ cả 4 tầng, đặc biệt là tầng 3, 4 nếu bỏ 2 tầng này thì coi như viết UT vô dụng.

Nói chung cân nhắc effort bỏ ra và lợi ích thu lại thôi. Mời các thím vào chém.

Nhấp để mở rộng...

cuoc_song đã nói:

Chọn cách 2 nhưng trực tiếp test từ controller bác ạ

Nhấp để mở rộng...

22mario9x đã nói:

Xưa làm dự án cũng tự mài mò viết unit test (cty làm product nhưng không có ai biết/bắt buộc làm unit test, nhưng được cái có thời gian rãnh).
Lợi của unit test là mỗi lần refactor thì run all test lại, để kiểm tra có ảnh hưởng phần khác không?
Khá là đỡ tốn thời gian

Nhấp để mở rộng...

tho go da nang đã nói:

Theo mình thấy qa/qc thiên về test kiểu user flow với product flow. Nói nôm na dễ hiểu là test chéo, để dev viết unit test đôi khi mindset sẽ khác nhau dẫn tới miss bugs. Nên thường qa/qc career path sẽ lên BA hoặc PM. Còn như bạn nói thì đúng rồi ai càng chuyên phần mảng nào thì càng thành công. Như dev nổi tiếng t.giới chưa thấy ai từ fullstack dev đi lên, còn phụ thuộc thêm chuyên môn bạn lựa hợp thị hiếu k nữa . Chứ h mà đâm đầu vào học chuyên java thì k tương lai lắm . Demand với supply thôi

Gửi từ Xiaomi Redmi Note 9S bằng vozFApp

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

Mô hình thường thấy trong các project hiện tại thì có 4 tầng như này:

1. MVC, MVVM tuỳ web hay desktop apps
2. Services
3. Data Access (ORM hoặc Repositories)
4. Database (stored procedures, triggers...)

Nếu viết unit tests kỹ thì 1 feature mới phải viết test cho cả 4 tầng này.

Tầng 1 là MVC, MVVM thì có thể viết UT cho controllers, viewmodels.. cái này ko có gì bàn cãi, cứ mock thằng services rồi viết thôi.

Các tầng 2, 3, 4 thì thật sự logic nặng nhất ở tầng 3 và 4. Services đa phần chỉ là gọi thằng 3 và 4 lên thôi. Hiếm lắm mới có cái services gọi nhiều repository hoặc gọi services khác với logic if else phức tạp. Trong khi đó cái tầng 3, 4 thì câu SQL query thường phức tạp hơn rất nhiều.

Giờ có 2 hướng chọn viết UT:
Cách 1. Viết unit test cho cả 4 tầng:

1. controllers (mock services)
2. services (mock data access)
3. data access (mock database)
4. database (viết test bằng SQL scripts để verify, stored procedure tests...)

Cách 2: Viết test cho 2 chổ:

1. controllers (mock services)
2. services (dek mock gì cả test thẳng từ services xuống database luôn). Các thím gọi nó là unit test hay integration test cũng được, ko quan tâm.

Tôi chọn cách 2 vì trong project thực tế, deadline dí liên tục thì có sh*t mà đủ time để viết test cho cả 4 tầng như cách 1. Hơn nữa cách 1 muốn đảm bảo test đúng thì phải test đủ cả 4 tầng, đặc biệt là tầng 3, 4 nếu bỏ 2 tầng này thì coi như viết UT vô dụng.

Nói chung cân nhắc effort bỏ ra và lợi ích thu lại thôi. Mời các thím vào chém.

Nhấp để mở rộng...

snake_case đã nói:

Repository thì mock sql là unit test được thôi. Cái gì ra cái đó, UT là UT mà IT là IT chứ.

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

Vẫn câu hỏi trên, hỏi thím kia nhưng chưa đc trả lời:

"Thế làm sao đảm bảo data lưu xuống database tables đúng?" Ví dụ gọi EmployeeRepo.Save(emp); EmployeeRepo.GetAll();..

Lỡ trong table employee có constraint not null, unique này nọ.. thì sao? Mock SQL để test code chay trên repo để làm gì khi mà cái quan trọng là phải insert record vào dc database.

Nhấp để mở rộng...

snake_case đã nói:

Migration script và model có khớp nhau hay không do lập trình viên viết và validate, kể cả anh viết unit test cho model cũng được.
Cứ mock rồi query matching cho đảm bảo trước khi chạy thật trên DB thôi chứ ai chả biết là phải insert vào được.

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

Nhưng vấn đề là anh thấy cái effort bỏ ra để viết UT trên repo nó vô dụng ko? Ngoài chuyện mapping model với table columns ra thì còn chuyện contraints ở data nữa.

Ví dụ Email là not null, có constraint dưới database nhưng lúc anh UT cho repo, a mock database thì cái mock của anh ko có constraint đó.

Còn chuyện UT cho model luôn thì thôi chỉ có trên lý thuyết, thực tế éo có test mọi chổ như a nói dc

Nhấp để mở rộng...

snake_case đã nói:

Anh viết bằng ngôn ngữ gì không biết chứ tôi vẫn viết unit test cái validate cho model bình thường với golang và java nhé

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

À ý là việc cân nhắc effort với ràng buộc về resource/deadlines trên project thực tế thôi.

Vì 1 cái dự án đang chạy nát bét rồi thì nếu có yêu cầu apply UT cho dự án phải cân nhắc nên test chổ nào, test thế nào như cách 1 hay cách 2 tôi nói ở trên để cân nhắc effort và hiệu quả thu dc.

Chứ 1 team 20 người code trăm hoa đua nở thì bảo UT cho đầy đủ, đúng kiểu split từng phần như được học thì ko dc...

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

Nhưng vấn đề là anh thấy cái effort bỏ ra để viết UT trên repo mà mock db nó vô dụng ko? Ngoài chuyện mapping model với table columns ra thì còn chuyện contraints ở data nữa.

Ví dụ Email là not null, có constraint dưới database nhưng lúc anh UT cho repo, a mock database thì cái mock của anh ko có constraint đó.

Còn chuyện UT cho model luôn thì thôi chỉ có trên lý thuyết, thực tế éo có test mọi chổ như a nói dc

Nhấp để mở rộng...

Khang.Hy.Gia.222 đã nói:

mock database thì phải giống. a cố tình làm sai r chê UT là thế nào?

code java tôi mock bằng hsqldb đây. có sao đâu

Nhấp để mở rộng...

Pepe.The.Frog đã nói:

OK vậy cho tôi hỏi a mock database mà giống 100% schema + constraints + triggers + permissions + logs + partitions + whatever được luôn hả?

Nếu giống 100% được thì sao ko clone cái db test cho nhanh? Lợi ích của việc mock để chi vậy?

Mock thì chỉ đảm bảo cái logic if, else… nó chạy đúng thôi chứ làm CRUD thì đa phần lỗi là do mis match giữa model với db. Chổ này là phải integration test luôn mới chắc ăn.

Nhấp để mở rộng...