프론트에서 테스트가 가능한가?

[익명(180.71)]

프론트에서 테스트가 힘든이유

1. 설계가 항상 깨지기 쉬움. 기획/디자인에 의해 레이아웃 자체가 쉽게 변경되고, 그 변경에 의해 코드를 갈아엎어야 하는 상황이 많음.

2. UI와 기능 분리 불가되는 케이스가 정말 한정적임. test 예제로 나오는 케이스들은 정말 단순하거나 예외적인 케이스

나는 그래서 테스트로 안정성을 가져가는것보다는

린터, 시스템화, 격리, 패턴화를 잘 해놔서 빠르게 문제를 발견하는쪽이 더 낫다고 본다.

[새싹볶음밥(dish90)]

프론트에서 유닛테스트가 가능한가 라는 주제는 논의의 여지가 있고 당장 나도 80%정도의 케이스에선 유닛테스트 필요없고 인터그레이션으로 충분하다고 생각하지만 프론트에서 테스트가 가능한가는 진짜 멍청한소리지 E2E는 필수고, 인터그레이션도 왠만하면 해야지 당장 유저와 직접 만나는게 프론트인데 테스트를 안하면 어쩌누

[익명(180.71)]

내가 말하는건 자동화 테스트가 필요한지 효용성에 대한 여부였음.

[새싹볶음밥(dish90)]

e2e랑 인터그레이션도 당연히 자동화해야지 자동화테스트가 유닛테스트만 가능한게 아니잖아

[익명(180.71)]

인터그레이션이든 유닛테스트던

[새싹볶음밥(dish90)]

니말대로 ui와 기능이 분리가 안된것들도 인터그레이션은 테스트할수있잖아...

[새싹볶음밥(dish90)]

가내수공업 수준의 서비스에나 하나하나 매번 수동테스트하는게 가능하겠지

[익명(180.71)]

자동화를 한다는게 '시스템'이 갖춰지고 그 시스템 하에서 자동화 가능할 수 있도록 하는건데... 그 시스템을 갖추기 위해서 얼마만큼 수준의 추상화를 구축할건지는 각 팀이 선택할 문제인거지. (룰이던, 플러그인이던 뭐든..) 불가능/가능 이라고 말하는것보다는 그냥 하는거 대비 얼마만큼의 효용이 있는지에 대한 의문인건데, 나는 대부분의 케이스에서는 (특히 IT서비스) 얼마만큼의 효용이 있는지 모르겠음. 왜냐면 그 추상화가 너무 쉽게 깨지기 때문에..

[익명(180.71)]

일반적인 서비스에서는 개인적으로는 그 비용대비 효용이 떨어진다 생각하고 어떤 서비스에서는 (그런 엄밀한 수동체크가 반드시 필요하고 그런거 때문에 불편함이 엄청 높은 서비스)는 불편함을 감수하더라도 추가하겠지.

[새싹볶음밥(dish90)]

디커플이 잘된 코드라면 유닛테스트를 적용하더라도 비용이 얼마 안들거고, 대부분의 프론트 코드들은 어쩔수없이 타협해서 커플링이 있음. 그래서 무언가 변경했을때 어디까지 영향이 미칠지 예상이 힘들어 니가 말하는 일반적인 웹서비스라는게 그냥 정적페이지를 말하는거야? 아니면 개인블로그수준? 그게 아니라면 웹어플리케이션에서는 도저히 말이 안되는데 당장 웹바이탈좀 떨어지는것도 매출과 직결되는데 테스트가 필요없다는게 말이되노

[익명(180.71)]

일반적인 웹 어플리케이션 프로덕트를 말하는거고, 다시말하지만 테스트는 필요한데 자동화 테스트를 구축할만한가에 대한 의문이었음. 그리고 너말대로 타협이든 뭐든 태생이 커플링이 존재할 수 밖에 없는데, 영향도를 어떤 기준으로 타고다니면서 체크할건지가 의문이야. 그럼 그 기준을 만들어줘야할거임. (패턴화를 시키든 뭘 하든..) 그걸 뭘로 만드냐 라고 했을 때 딱 명확히 나오는게 없다 이거지. 그래서 나는 이렇게 테스트를 하는것보다 각 컴포넌트간의 격리가 더 중요하다고 생각.

[익명(180.71)]

일주일에 한번씩 배포나가고 신규피처도 계속 나갈 수 있는데 테스트 유지보수까지 들어가게 될 확률이 높다는거. BE나 모바일은 애초에 그런거 상관없이 디커플링 잘되는 구조라서 상관없는데 FE는 그것도 안되니 BE에서 하던방식으로 비비면 안된다는 의미.

[익명(180.71)]

나는 어떤방식으로 자동화 하는지 궁금하긴하다. 어떻게하는데 너는?