가령 백엔드를 예로 들면
DB 설계랑 API 인터페이스 딴딴하게 설계 잡아두고
여기에 e2e 테스트 프로그램 미리 싹 발라뒀다면
메인 프로그램 코드 막 대충 짜도 됨
어차피 잘못된 로직은 테스트 프로그램에서 걸릴거고
테스트 프로그램 덕에 리팩토링 전후로 되던거 안되고 이런거 없어서
리팩토링도 자신감 있게 팍팍 쳐낼 수 있음
-> 이게 어딜봐서 막 짜는거임? 하면 할 말 없긴 함 ㅋㅋㅋ
아무튼 본인은 코드를 예쁘고 간결하게 짜는거보다
테스트 코드 갖추는걸 우선순위로 보는데
이거 시니어쉑들도 "나는 예쁜 코드를 잘 짜요" 드립만 치고
테스트 제대로 못 짜는 애들 수두룩하게 봤다
그리고 리팩토링 하면서 버그 오질라게 싸지름 ㄷㄷㄷ
결론) 아무튼 테스트 잘 짜는게 짱임
테스트 드리븐이 사실 갓갓이긴 하더라 테스트 코드 맨 처음에 배울때 클래스, 함수의 역할을 분리해서 생각하는데 도움이 엄청 됐음
나도 이번에 패키지 하나 갈아엎으면서 테스트코드 덕을 진짜 많이 봤음. 든든하더라
대단하네, 선 테스트 체계 도입할라치면 어느 회사를 가나 시니어들 랄지해서 항상 골치아프다
관련된 책 추천가능?
책으로 배운거 아녀서 나두 몰루
해당 댓글은 삭제되었습니다.
클라이언트/프론트에겐 도움 되지
근데 진짜 테스트 짜놓으면 뭐 고칠때 안심되긴 함
아 이제 뭔지 감이오네 ts로 짜면 알아서 테스트 코드를 생성해준다고?
ㅇㅇ nestia는 초기 e2e 테스트 코드 자동으로 만들어줌
프로퍼티는 어떻게 찾아내는거임 리플렉션이라도 만들어씀?
아니, 컨트롤러랑 DTO 소스코드 분석해서 해주는거임
이 경지까지 가기가 어렵다리
테스트는 한번 맛을 봐야 값어치를 알게 됨 ㅋ 근데 테스트 때문에 구조를 Testable하게 바꿔야 되는 부작용이 있음.
그래서 애초에 Boilerplate 만들때 무조건 테스트 낑궈 넣고 빌드되게 시작하는게 좋더라규.
이거 ㄹㅇ인게 몇년동안 계속 갈아엎던 플젝 받아서 했는데 도무지 답이 없어서 테스트케이스 함수단위로 컴포넌트단위로 다 만들어서 개발하니까 그래도 돌아가는 수준으로 1년만에 만들었다