1주차 미션을 해결할 때 가장 고민했던 부분은 숫자 야구 게임이 콘솔이 아닌, 현실에서 진행 된다면 어떻게 할 수 있을까에 대한 고민이였다. 현실이라면, 게임의 참여자들을
으로 나눌 수 있고 각 참여자의 책임을 구분해서 참여자별로 클래스를 만들면서 구현했다. 따라서, 폴더구조도
📦src
┣ 📂constants
┃ ┣ 📜Conditions.js
┃ ┣ 📜ErrorMessages.js
┃ ┣ 📜GameMessages.js
┃ ┗ 📜PlayerSigns.js
┣ 📜App.js
┣ 📜Computer.js
┗ 📜Player.js
위와 같았다.
1주차 때 적용한 방법은 각 클래스만 확인하면 게임 참여자들의 책임을 바로 확인할 수 있다는 장점이 있었지만 한편으로는 관심사 분리측면에서는 좋지 못한 코드인 것 같았다. 게임 진행자(App)는 게임 진행과 게임 진행 상황을 출력하는 책임을 모두 가지고 있어 생각보다 코드가 길어지는 것 같다는 생각을 했다. 2주차에서는 참여자별로 분리하지 않고, 관심사 분리에 집중하기로 했다.
MVC 패턴은 비즈니스 로직과 화면을 구분하는데 중점을 두는 소프트웨어 디자인 패턴이라고 한다.참고
자동차 경주를 진행하는 로직과, 화면을 통해 입출력을 진행하는 로직을 구분하면 1주차 때 발견했던 단점들을 해결할 수 있을 것 같아 적용해보기로 했다.
본격적으로 코드를 작성하기 전 설계도를 그리고 최대한 설계도에 맞춰서 자동차 경주를 구현해보기로 했다.
어떻게 구현해나갔는지는 여기에서 확인할 수 있다. 😊
2주차 부터는 함수를 분리하고, 함수의 기능을 테스트해야 했다. 1주차 미션을 해결할 때만 해도 따로 테스트 코드를 작성할 필요가 없어 ApplicationTest.js
에 있는 코드를 해석해보지 않고 npm test
를 통해 진행되는 테스트가 통과되는것에만 집중했다.
2주차 부터 직접 테스트 코드를 작성해야 했기에, 우선 ApplicationTest.js
에 있는 테스트 코드 부터 분석해보기로 했다.
mockRandoms
, mockQuestions
등등.. 무언가를 모킹하는 함수들이 있었다. 우선 모킹에 대해서 알아야 했다.
함수가 함수 외부에 있는 module, function들을 사용해서 어떤 기능을 제공할 때, 그 함수는 외부 요소에 의존하게 된다. 단위 테스트에서 테스트하고자 하는 함수(코드)가 의존하는 module, function에 대해 모조품을 만들고 일단 그 기능이 돌아가게 하는 것을 mocking이라고 한다.
한마디로, 어떤 코드를 테스트 할 때 그 코드가 의존하는 부분을 가짜(mocking)로 대체하는 방법을 말한다.
테스트 하려는 함수의 기능이 다른 요소, 기능들과 엮여있을 경우 오직 그 함수의 기능을 테스트하기 힘들기 때문이다.
예를 들어 회원가입 처리를 잘 하는지 테스트하기 위해서 request body에 id, password를 전달하면 정보를 추출해서 데이터베이스에 넘기는 역할을 하는 함수의 기능을 테스트 하는 상황을 가정해보자.
이 때, 실제 데이터베이스를 사용해서 테스트 하는 것은
이러한 문제들이 있기 오직 함수의 기능만 테스트하기에는 한계가 있다.
모킹 함수를 사용하면 기존의 데이터베이스에 추출한 id, password를 전달하는 함수가 반환해야 할 값을 우리가 임의로 지정할 수 있다. 테스트 하려고 하는 것은 외부 요소에 의존하지 않았을 때 함수의 기능이므로 “외부 요소들을 전혀 고려 하지 않았을 때, controller 메서드는 ~~값을 반환하도록 하자”라고 가정하는 것이다.
즉, 테스트를 위한 mocking(모조품) 함수를 만드는 것이다.
jest.fn()
, jest.spyOn()
)Application.js
테스트 코드 분석Model
(Car, CarRace), Controller
(CarRaceController) 기능 테스트들은 여기에서 확인할 수 있다.😊
JS MVC는 희귀하네요~! 멋지세요~!