private 상수 테스트 관련 질문

안녕하세요, eunseo lay 님!테스트에서는 MAX_FILE_SIZE를 직접 참조할 필요 없이 10 이라는 숫자를 그대로 사용하시면 됩니다.반대로 이야기하면, 테스트 코드에서는 프로덕션 코드의 상수 값을 참조해서는 안 됩니다.왜 그럴까요? 만약 MAX_FILE_SIZE를 직접 참조하는 테스트라면, 10이라는 숫자를 누군가 실수로 100이라고 고쳤을 때 테스트 코드는 여전히 통과하지만, 실제로는 치명적인 문제를 일으킬 수 있습니다.테스트 코드의 본래 목적인 이상 감지가 동작하지 않는 것이죠.즉, 상수를 직접 참조하는 경계값 테스트는 상수 값에 관계 없이 항상 통과하는 테스트를 작성한 셈입니다.만약 상수를 직접 참조하는 것이 아니라 10이라는 숫자를 그대로 사용했다면, 100이라고 잘못 고치는 순간 테스트는 실패할 것이고, 개발자는 10을 100으로 고친 것이 의도한 것인지, 단순 실수인지를 파악할 수 있게 됩니다. 최소한의 안전 장치가 생기는 것이죠.도움이 되셨기를 바랍니다.감사합니다. 🙂

[강의 질문] 메서드 선언부

안녕하세요, JuNu 님!좋은 질문이네요. '추상과 구체', '추상화 레벨' 강의에서 살펴 보았듯이, 추상화 레벨이 높은 메서드명은 구현체의 모든 내용을 담을 필요가 없습니다. 추상화 단계가 올라가면서 자연스레 생략되는 구체의 정보가 생기기 마련입니다.위의 예시에서는, '게임이 끝났는지 체크'하는 것은 메서드의 목적으로 추상화 레벨이 높고, '셀이 열렸는지 체크'하는 것은 게임이 끝났는지 체크하기 위한 구체적인 방법으로 추상화 레벨이 낮습니다. (즉, 구체에 가까운 정보입니다.)만약 읽는 사람이 checkIfGameOver()라는 메서드를 읽고 '게임을 끝냈는지 어떻게 체크했지?'라는 궁금증이 든다면, 그 때 추상화 레벨이 낮은 메서드 구현부로 진입하여 내용을 읽고 '셀이 모두 열렸는지를 체크하는구나!' 라는 정보를 얻을 수 있습니다. 반대로 구체적인 내용에 관심이 없는 사람은 메서드명으로 충분한 정보를 얻고 넘어갈 수도 있을 거고요.도움이 되셨기를 바랍니다.감사합니다. 🙂

[강의 질문] 메서드와 추상화

안녕하세요, JuNu 님!네, 항상 선택은 개발자의 몫입니다. '어느 정도까지 메서드를 분리해야 해?'라는 질문에는 '읽는 사람의 이해를 돕는 방향으로'라고 답할 수 있겠습니다.만약 도메인의 맥락상, 그리고 현재 로직의 흐름상, 설계한 메서드의 구조가 충분히 의도를 전달하고 있지 못하다면, 메서드 분리를 통해 추가적인 의미를 전달할 수 있을 거예요. 반대로 적절한 추상화 단계를 가지고 있다고 판단한다면 거기서 메서드 추출을 멈출 수도 있겠죠. 정해진 답은 없으니 상황에 따라 잘 판별하시면 되겠습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

void는 어떻게 테스트하나요..? void로 애초에 코딩하면 안되나요??

안녕하세요, 한지찬 님!몇 가지 명제들을 제시하며 답변 드리겠습니다.테스트를 위해서 void 메서드를 억지로 반환값이 있는 형태로 바꾼다. (X)메서드의 의미상 반환 값이 존재하는 형태가 더 자연스럽다면 void 보다는 반환 값이 있는 형태가 여러모로 좋다. (O)이 때 검증은 반환되는 값이 예상한 값과 일치하는지 확인하는 방법을 사용할 수 있다.메서드의 의미상 void가 더 자연스럽다면 void로 만드는 것이 좋다. (O)이 때 검증은 verfiy 등을 활용할 수 있다.테스트 코드와 프로덕션 코드는 공존하는 관계여야 하며, 테스트의 용이함을 위해 프로덕션 코드를 그에 유리한 쪽으로 변경할 수는 있지만, 해당 행위가 본래의 그 의미를 해칠 정도로 과해서는 안 됩니다. verify를 사용하는 것이 잘못된 방법도 아니고요. 여러 존재하는 검증 방법 중 적절한 방법을 찾아 선택하는 것이 중요하겠습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

DIP 개념에 대한 질문입니다.

안녕하세요, 인생은회전목마 님!맞습니다. 하위 객체의 구현 내용이 변경되는 것은 어차피 상위 객체에서 알 수 없기 때문에 그것을 이야기하는 것은 아니고요.상위 객체가 하위 객체를 직접 참조하게 되면, 일단 해당 하위 객체의 이름부터, 패키지(참조 위치), 말씀하신 메서드 시그니처까지 모든 정보를 다 알고 있게 됩니다.구현체도 하나로 고정되기 때문에, 요구사항에 변경이 생겨 A 구현체가 B 구현체로 변경되어야 하면 A 구현체를 직접 의존하고 있는 모든 상위 객체가 변경이 필요해집니다. 만약 100군데라면 100개의 파일에 변경이 일어나겠죠.하지만 이미 잘 아시는 것처럼 인터페이스를 활용해 의존 방향을 역전시키면, 상위 객체는 구현체의 기능(스펙)만 알지 실제로 어떤 구현체가 연결되는지는 알 수 없습니다. 애초에 관심을 가질 필요도 없는 것이고요.도움이 되셨기를 바랍니다.감사합니다. 🙂

만약 보드를 이용한 게임의 종류가 더 다양해진다면 어떻게 될 수 있을지에 대한 고민

안녕하세요, wjdghks5698 님!좋은 질문이네요. 요구사항에 따라 구현 방향이 달라지겠지만, 아마 하나의 GameBoard 구현체를 두고 여러 게임이 공유한다면 기능을 정말 잘 세분화해야 할 것 같아요.보드판 자체가 그저 판을 생성하고, 기물을 표시하는 정도의 역할을 갖는다면 대부분의 보드판 게임에서 필요한 기능이니 말씀하신대로 가능할 것 같아요.조금이라도 각 게임에 특화된 기능이 보드판에 필요한 상황이라면, 오히려 게임 별로 보드판을 두는 게 향후 유지보수에 편할 수도 있습니다. (보드의 기능을 중복해서 만드는 불편함이 있겠지만요)지금 가볍게 생각하기에는 공통의 보드판을 사용하는 게 가능할 것 같네요. 주어진 요구사항을 중심으로, 그리고 미래에 발전 가능성이 높은 방향으로 의사결정하고 프로덕트를 설계하시면 됩니다. 보드처럼 여러 곳에서 활용되는 기능이 잘 분리되어 재사용되고 확장되는 것을 목표로 해보면 좋을 것 같네요.감사합니다. 🙂

DIP 설명 후반부에 IOC에 대한 질문 드립니다.

안녕하세요, 인생은회전목마 님!먼저 컴파일 타임과 런타임 시점을 구분해서 이해하셔야 합니다. DIP가 적용되지 않은 코드는 인터페이스 없이 상위 모듈이 하위 모듈을 직접적으로 참조하고 있게 됩니다. 컴파일 타임부터 어떤 객체를 참조할지 알고 있게 되는 것이죠. DIP가 잘 적용되어 인터페이스로 참조할 구현체의 기능만 알고 있고, 직접적인 구현체 자체는 알 수 없는 구조라면, 컴파일 시점에는 알 수 없지만 실제 실행 시점인 런타임 시점에 구현체를 주입받게 됩니다.스프링 IOC의 장점을 설명하라고 하면 제어의 역전이 되면서 구현 인스턴스 변경에 유연해진다라고 들었는데위와 같이 표현하신 것처럼 직접 참조가 아닌 인터페이스를 통한 참조라면 하위 모듈인 구현체 객체가 변경되어도 (인터페이스 스펙만 유지한다면) 상위 모듈이 영향을 받지 않습니다. 그렇기에 "변경"에 유연해진다고 하는 것입니다. 구현체가 꼭 하나만 있는 상황 말고도, 스프링에서는 런타임 시점에 여러 구현체(Bean) 중 상황에 맞는 것을 선택하여 주입할 수도 있습니다. 이처럼 동일한 인터페이스 스펙만 유지된다면 구현체를 얼마든지 교체할 수 있기 때문에, 스프링 IoC는 변경에 유연한 구조라고 할 수 있습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

안녕하세요 ! 혹시 자바가 아닌 다른 객체지향 언어를 알고있어도 강의를 들어도 괜찮을까요 ?!

안녕하세요, 박시콩 님!네, 그럼요! 충분히 가능합니다. 특정 언어의 고급 기능을 사용하는 예제가 아니라서, 모르는 문법이 나와도 그때마다 가볍게 학습하면서 진행하시면 충분히 따라가실 수 있습니다. (요즘은 또 GPT가 잘 알려주니까요~)감사합니다 🙂

안녕하세요 메서드명 때문에 고민이 있어서 질문드립니다.

안녕하세요, III 님!어느 방법이 무조건 더 좋다고 말하기는 어려운데요, 상황에 따라 선택하시면 될 것 같아요.Tip 이라는 도메인의 특성이 항상 save 행위을 기반으로 동작해야 한다면 1번이 더 편할 것이고, 그렇지 않고 저장이 아닌 다른 행위만 수행하는 경우도 있다면 2번을 고려해볼 수도 있을 것 같네요.Builder의 경우는 객체 생성에 관련된 코드이니, 저는 객체(여기서는 Entity) 안에 넣고 있습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

커버리지는 어떻게 활용하시는지 궁금합니다.

안녕하세요, seonrizee 님!저는 다음과 같이 생각합니다.커버리지 자체를 중요하게 신경쓰는 것 보다는 중요도에 따른 도메인/비즈니스 로직에 집중하여 테스트 코드를 작성하는 것이 맞다.다만, 팀 내에서 커버리지 자체에 대한 최소 기준을 가져가는 것은 팀원 모두가 의식적으로 테스트 코드를 꾸준히 작성하게끔 하는 동력이 될 수 있다.ex. 우리 팀의 최소 라인 커버리지는 60%로 정한다. (향후 커버리지가 더 좋아지면, 65, 70% 로 높여서 적용해나갈 수도 있음)감사합니다. 🙂