레벨 1 을 끝 마치며
테스트 코드 꼭 작성해야 할까?
테스트 코드를 작성하려면 많은 시간을 할애해야 한다. 그리고 테스트 코드는 프로덕션 코드에 어떠한 영향도 미치지 않는다. 그럼에도 테스트 코드를 작성해야 할까? 저는 테스트 코드 작성에 레벨 1 동안 항상 부정적인 생각을 가지고 있었습니다. 코드를 잘 작성하면 테스트를 작성할 필요가 없을 것이라고 생각했습니다.
- 일단 코드를 잘 작성할 확률이 적습니다. 코드를 맞게 작성하더라도 화면 단에서는 에러가 많이 발생하죠. 그래서 테스트 코드를 작성한다면 전체적인 기능들의 에러를 한 눈에 볼 수 있습니다.
- 협업을 한다고 생각했을 때 제가 작성한 코드를 다른 개발자가 테스트할 때 테스트 코드가 작성 되어있다면 하나하나 직접 화면 단에서 테스트하는 수고를 덜 수 있습니다.
이러한 이유로 인해 테스트 코드를 작성하는 비용이 개발자가 직접 테스트하는 비용보다 적다는 것을 알 수 있습니다. 그리고 프로젝트 규모가 좀만 커지면 이 비용을 절실히 느낄 수 있습니다. 기능이 점차 많아지고 기능별로 상관 관계를 가진다면 직접 테스트할 때의 비용이 배로 커지는 것을 느낀 후로 테스트 도입이 필수불가결한 것 같습니다.
개발자는 중복되는 코드를 불편해합니다. 그래서 테스트 코드를 작성할 때 중복되는 코드를 줄일 수 있는 키워드가 있습니다.
-
before()
before()는 모든 테스트 전에 한번 실행해야하는 로직을 넣는 것이 좋습니다
describe("상품 관리 탭 테스트", () => {
before(() => {
// 로그인 로직
cy.visit("http://localhost:9000/#product");
cy.get(".member-login-button").click();
cy.get(".member-info-input").eq(0).type("examle@gmail.com");
cy.get(".member-info-input").eq(1).type("examle!");
cy.get(".member-confirm-button").click();
cy.waitUntil(() => cy.location('hash').should('eq', '#product'));
})
it("자판기에 상품 추가가 기능하다", () => {
cy.get("@productNameInput").type("사이다");
cy.get("@productPriceInput").type(PRODUCT.MAX_PRICE);
cy.get("@productQuantityInput").type(PRODUCT.MAX_QUANTITY);
cy.get("#product-add-button").click();
cy.get(".product-name").should("have.text", "사이다");
});
});-
beforeEach()
테스트 코드는 공통되는 기능을 테스트 할 때 묶어서 테스트하는 것이 좋습니다. describe()안에 여러 테스트가 있드면 각각의 테스트가 실행되기 전에 beforeEach()안에 있는 로직을 실행하고 테스트가 진행됩니다
describe("상품 관리 탭 테스트", () => {
beforeEach(() => {
cy.get(".product-control-input").eq(0).as("productNameInput");
cy.get(".product-control-input").eq(1).as("productPriceInput");
cy.get(".product-control-input").eq(2).as("productQuantityInput");
})
it("자판기에 상품 추가가 기능하다", () => {
cy.get("@productNameInput").type("사이다");
cy.get("@productPriceInput").type(PRODUCT.MAX_PRICE);
cy.get("@productQuantityInput").type(PRODUCT.MAX_QUANTITY);
cy.get("#product-add-button").click();
cy.get(".product-name").should("have.text", "사이다");
});
});타입스크립트를 못 잊는 이유
항상 미션 프로덕션 코드 작성 전 미션에 대한 전체적인 설계를 하고 설계한 방향대로 코드를 작성합니다. 타입 스크립트를 사용한다면 역할에 따라 설계한 클래스가 할 일을 설계할 수 있습니다. 클래스가 할 일을 설계하면서 이 클래스가 올바른 역할을 수행하는지를 확인할 수 있습니다.
어떤 라이브러리나 프레임워크, 도구를 사용해야 하는 저만의 이유를 찾는 순간부터 관심이 생깁니다. 자판기 미션에서 타입 스크립트로 미션을 끝마치고 자바스크립트로 구현되어 있는 개인 프로젝트를 리 팩터링 하는 도중 저는 타입 스크립트가 너무 그리웠습니다. 자바스크립트는 자유성이 높은 언어에 속합니다. 자유성이 높은 만큼 그에 따르는 책임은 매우 커집니다. 그 책임은 모두 개발자가 떠안고 가죠. 그 책임을 타입 스크립트를 도입함에 있어 줄일 수 있습니다.
- 타입스크립트는 정적 타입 언어기 때문에 자바스크립트처럼 동적 타입 언어에서의 값의 타입이 변경될 걱정을 할 필요가 없습니다.
- 타입스크립트는 컴파일 시점에서 자바스크립트 코드에 대한 에러를 잡아줍니다. 그래서 코드 실행 후에 에러가 발생할 확률이 줄어듭니다.
- 타입스크립트는 점진적으로 도입할 수 있습니다. 개발자가 필요한 상황에서만 타입스크립트로 마이그레이션 할 수 있습니다.
should do X, must do 사용자 고려
Front enginer, FE 개발자라고 줄여서 부릅니다
저는 항상 F와 E 중 E에 대해서만 집중하고 학습도 E의 실력을 위해 많은 노력을 기울였습니다. 그래서 미션에서도 사용자는 저뿐이기에 F를 신경 쓰지 않고 관대한 사용자만이 있는 세상의 서비스를 만들었습니다. 그러나 실제 세상에는 너무나 미친 사용자들이 많습니다. 저 역시 마찬가지입니다. 제가 사용하는 영어 공부 서비스에서 정답 버튼이 있으면 정답 제출할 때 미친 듯이 정답 버튼을 눌러보고 정답을 제출한 순간 제가 고른 정답을 바꿔보는 짓을 합니다. 출시된 지 얼마 되지 않은 서비스여서 그런지 정답 버튼을 미친 듯이 누르면 레벨 통과 게이지가 쭉쭉 올라가는 등의 버그가 있더군요.
포코의 F에 대한 피드백을 받은 이후 제가 간과하고 있었던 것을 다시 상기할 수 있었습니다. 제 서비스에는 관대하고 다른 서비스에서는 미친 사용자가 되어간 저를.
토스라는 서비스를 예로 들면 토스에서 어떤 콘텐츠에서 사용자 동의가 필요할 때 정말 생각 없이 모든 조항에 동의하는 저를 볼 수 있습니다. 이렇게 물 흘러가듯이 콘텐츠 사용에 대한 사용자 동의를 얻는다면 사용자의 이탈률이 정말 적을 것이라고 생각합니다. 그래서 이번 레벨의 마지막 미션인 자판기 미션에서 사용자에게 친절한 서비스를 만들 수 있는 좋은 미션이라고 생각해서 부단히 노력을 하였습니다. 하나를 예로 들면, 회원가입 페이지에서 사용자가 입력해야 하는 값에 대한 제약사항이 많습니다. 그래서 input에 값을 작성하고 마우스를 다른 곳을 클릭(다음 input으로 넘어가는) 할 때 입력한 값에 대한 유효성을 검사를 하고 결괏값을 input 하단에서 보여주었습니다. 유효성 검사가 실패한 이유에 따라 텍스트를 보여주었고 성공 시에도 사용자를 칭찬하는 듯한 텍스트를 보여주었습니다.
이렇게 사용자에게 편리하고 친절한 서비스를 만들기 위해서는 개발자에게 상당한 어려움이 따릅니다. 이러한 어려움을 이겨내야 사용자에게도 편리한 서비스, 개발자에게도 사용자 이탈률이 적은 서비스를 만들 수 있습니다.
포코조 나이스~~
포코조 나이스 ㅋㅋ ㅋㅋ