우아한테크코스 프리코스 2주차 문제 풀이 복습

이 글에는 문제에 대해서만 딱딱하게 적혀있습니다

개인 복습용 노트 느낌으로 작성한 것이기 때문에 큰 도움이 되지 않을 수도 있습니다

 

2주차를 통해서 얻을 수 있었던 것

1. 전체 프로그래밍 과정의 프로세스에 대한 정립

전체 흐름 작성

흐름 속에서 생길 수 있는 모든 개념 작성

개념들에 대해서 단위 테스트를 작성함

2. 추상화를 통한 테스트 가능한 코드들

출력같은 경우 바로 System.out.println을 통해 출력하게 된다면 이 부분을 테스트 하기 정말 어려움

중간에 객체가 하나 있고, 그 객체에 제대로 값이 전달되는 것만 확인한다면 그 자체로 충분할 수 있음

3. 중간 구현체를 두는 상황에서의 인터페이스의 유효성

중간 구현체는 당연하지만 실제 클래스가 되었을 경우 너무 강하게 결합되어서 추후 분리가 어려움

이때 인터페이스를 이용해서 관리하면 훨씬 테스트 하기 편해짐

4. 변경에 유연해지는 코드들

인터페이스를 통한 관리

생성자를 통한 주입으로 테스트 가능한 코드들

5. 주석 달기의 중요성

주석을 달려고 하는 순간 생각보다 많은 것들이 보인다

모든 public 메서드에 대해서 주석을 달려고 하면 이게 진짜 필요한 지를 확인할 수 있다

진행 순서와, 구현 기능 목록은 달라야 한다 

2주차에서 달성하고 싶었던 목표

1. 단위 테스트를 만든다

기능 목록에 해당하는 개념에 한해서 tdd를 진행한다

기능 목록을 묶어서 사용하는 큰 개념에 있어서는 단위 테스트를 달 필요가 없다

2. 주석을 단다

JavaDoc의 방식을 사용해서 정리하도록 만든다

3. 개념적으로 최대한 분리한다

기능 목록을 개념적으로 분리하는 방식으로 사용해서 진행한다

4. 패키지를 나누는 기준을 정립한다

패키지는 무조건 도메인과 view에 대해서 먼저 나누고 시작한다

그리고 코드를 구현한 이후에 함께 변경될 거 같은 부분을 묶어서 하나의 패키지에 놓는다

모든 기준은 변경 가능성에 따라 생각해야 한다

 

1. 문제에서 나올 수 있는 진행 순서를 만든다

1. 사용자에게 출력을 해준다

2. 컴퓨터는 랜덤 값을 만들어 내야 한다

3. 사용자가 입력을 하면 조건에 맞는지 검증한다

4. 사용자가 입력한 결과와 랜덤 값을 비교한다

5. 점수에 따른 결과를 출력한다

6. 모두 맞혔을 경우 게임을 종료한다

7. 재시도 여부를 플레이어에게 묻는다

8. 재시도 하거나, 종료한다

2. 숫자 야구 기능 목록

숫자 야구에 들어가는 모든 개념을 나열해보는 과정부터 시작한다

코딩 과정에 필요할 수 있을 것같은 모든 개념적인 부분들을 다 나열한다

1. 볼(0~3)

enum으로 관리한다

2. 스트라이크(0~3)

enum으로 관리한다

3. 입력

일단 라이브러리 함수를 그대로 사용한다

4. 출력

일단 라이브러리 함수를 그대로 사용한다

5. 1자리 숫자로 쪼갠 숫자들 0~9까지

enum으로 관리한다

6. 숫자들을 묶어 만든 정답

일급 컬렉션으로 5번 enum을 묶어서 관리한다

7. 입력을 통해 만들어진 사용자의 입력

일급 컬렉션으로 5번 enum을 묶어서 관리한다

8. 1,2에 따른 종료와 시도 여부

enum으로 관리한다

9. pickNumberInRange를 통해 구현되는 랜덤값

일단 라이브러리 함수를 그대로 사용한다

10. 숫자 점수 계산

사용자의 입력과, 랜덤값을 비교한다

 

이 10가지만 있으면 모든 코딩이 될 수 있는지 생각한다 

있을 거 같으면 여기서 멈추고 끝낸다

 

3. 단위 테스트를 작성한다

단위 테스트를 어디까지 작성해야 하는가?

1. 단위 테스트를 모든 코드에 대해서 작성할 수 있다

2. 단위 테스트를 최소한에 것에만 작성할 수 있다

3. 적당히 눈치껏 작성할 수 있다

 

여기 있는 기능 목록 정도까지는 단위 테스트를 만드는 것이 가장 적절하다고 생각합니다

이 이상의 경우에서는 "단위"테스트 라는 목적에 부합하지 않는다는 생각이 들었습니다

 

2번째 만들 때 실제로 모든 과정을 진행하는 컨트롤러, 게임이라는 객체들이 있었는데, 이 코드들은 IO를 담당하는 경우가 많았고, 테스트 하는 과정을 생각하다보니 너무 큰 단위로 테스트 되어서 바깥의 ApplicationTest를 따라가는 것이 좋다는 생각을 했습니다

이에 통합 테스트 쪽이 더 직관성과 퀄리티에 좋을 거 같다는 생각을 했습니다

 

TDD 라이프사이클을 생각한다

실패하는 테스트 작성, 작동하도록 만들기, 리팩토링

"단위 테스트"를 적용할 수 있는 부분에 있어서는 먼저 테스트 코드를 작성합니다. 그 외적인 부분에 테스트 케이스에 대해서만 생각합니다