canh_1412
Senior Member
Viết rồi lại ước giá như pj đừng bắt unitestGiống em rồi đấy, đi làm hơn năm mà vẫn chưa phải viết unit test @@

Viết rồi lại ước giá như pj đừng bắt unitestGiống em rồi đấy, đi làm hơn năm mà vẫn chưa phải viết unit test @@

Viết UT cực NHƯNGViết rồi lại ước giá như pj đừng bắt unitest![]()
Nếu bác làm outsource có team tester chịu trách nhiệm toàn bộ phần test/bug thì làm vậy dc.Viết rồi lại ước giá như pj đừng bắt unitest![]()



Có gì đau mà quê. bug prod là chuyện bt. Có bug thì fix. unitest đa sô toàn tìm cách coverate lơn hơn 80%.Nếu bác làm outsource có team tester chịu trách nhiệm toàn bộ phần test/bug thì làm vậy dc.
Chứ làm product, bản thân mình chịu trách nhiệm code đưa lên, bị reviewer moi bug ra thì quê lắm
Chưa kể là cái cảm giác mông lung k biết mình có nhỡ tay làm sai lệch cái gì ko, đưa lên prod mới lòi ra thì cực gấp mấy lần, cảm giác cực kì ko chắc chắn khó chịu. Cứ phải có cái test, run phát mới nhẹ nhõm bác ạ
Mà đôi khi còn test thiếu nữa![]()
Có thì tốt, Và thường là băt buộc để tránh mấy lỗi basic. Thê khi chú code ko test trên dev, stg ah.Viết UT cực NHƯNG
Ngay cả con pet project tui vẫn phải viết UT nữa nè.
- Đảm bảo quality trước khi release. Chứ chờ lên PROD mới biết thì sml !
- Local testing dễ dàng
- Nó cũng là 1 phần của CI/CD flow

cũng tuỳ công ty thôi ... việc viết UT để đảm bảo bạn code ổn - ổn ở đây là bạn biết bạn viết gì ... IMO, có UT mình thấy ổn nhất khi refactor nhấtHình như có QA/QC vẫn phải viết UT phải không các bác? Chưa làm công ty lớn bao giờ lên không biết



vậy thì test làm gì nữa bang chủ, nó đi ngược vs cái tác dụng chính của test mang lại rem fresher đang làm cho cty outsource, quy trình của client cũng khá chuẩn chỉ, dùng Azure Devops, có pipeline đầy đủ hết, bắt viết unit test 80%. Nhưng dev ở cty lại khá lười, khách kêu code theo structure 3-layer, mà leader + dev của cty thì cứ nhét hết code vào 1 layer, unit test thì viết qua loa, thậm chí chặn luôn nhiều file để tăng % lên![]()

viết UT để lấy coverage là chính, Assert.True() luôn, chất chơi chưavậy thì test làm gì nữa bang chủ, nó đi ngược vs cái tác dụng chính của test mang lại r![]()


Quy trình ẩu quá, mà chắc lĩnh vực t vs bang chủ hơi khác chứ phân nửa số test t viết trước cả khi bắt đầu code rviết UT để lấy coverage là chính, Assert.True() luôn, chất chơi chưa
sửa code xong push lên build, fail UT nào thì ta comment UT đó lại rồi build tiếp, sau này rảnh thì ta viết UT cover lại sau nhé, okay hônq![]()

Outsource từ ngày xưa chủ yếu làm với Nhật, nên học luôn quy trình từ họ. Còn outsource đợt bùng nổ it thì làm nhanh còn thu tiền nên cắt hết quy trình, khách trả tiền để làm gì thì mới làmOutsource hay opensource vậy thím?
Mà hồi trước outsource đúng chuẩn chỉ quy trình, bây giờ cty outsource nhan nhản, làm việc y như thớt nói, nhất là vụ ssh vào sửa = ))
View cos ra com ra chao gi hem ta ?Ko ưng thì cook thôi bạn. Thông thường outsource quỳ trình phải nhiều hơn product chứ. Lên đây nói ngược câu view để thể hiện quan điểm à?
Ba các concept cũ mèm, ko biết muốn thể hiện gì. Chắc ra ngoài đời người ta thấy nói chuyện kiểu lưu manh, khôn lõi nên ko ai giải ngố cho, thành ra giờ vẫn phải lên đây chửi đổng.
Fowler, Martin (1 May 2006). "Continuous Integration".
“Object-Oriented Programming” (OOP) was coined by Alan Kay circa 1966 or 1967
Giả khùng giả điên nói chuyện vô nghĩa à. Hay log clone nhiều quá nên mất trí rồi thằng lú.View cos ra com ra chao gi hem ta ?
Gluck. Reported. UneducatedGiả khùng giả điên nói chuyện vô nghĩa à. Hay log clone nhiều quá nên mất trí rồi thằng lú.
Cay nhất cái vụ lúc trên mtr dev/uat thì test tủng các thứ ok, đến hôm golive lên prod lại dính lỗi liên quan đến permission. Cay thật sự


UT hay gi gi cung dau the dam bao 100%.Viết Unit test thì cx chỉ là chạy trên mtr dev/uat. Xong lên mtr Prod vẫn lỗi như thgCay nhất cái vụ lúc trên mtr dev/uat thì test tủng các thứ ok, đến hôm golive lên prod lại dính lỗi liên quan đến permission. Cay thật sự
![]()