아기개발자의 성장일기

단위 테스트 8장~10장 (Part 3. 통합 테스트) / 11장 (Part 4. 단위테스트 안티패턴) 내용을 기반으로 하고 있습니다. 8장 통합 테스트를 하는 이유 # 통합테스트의 역할 통합테스트는 시스템이 프로세스 외부 의존성과 통합해 작동하는 방식을 검증한다. 단위테스트 - 도메인 모델 및 알고리즘 확인 통합테스트 - 컨트롤러 확인 // 외부의존성과 도메인 모델을 연결하는 코드를 확인 다시 한번 강조하지만, 모든 테스트는 도메인 모델과 컨트롤러 사분면에만 초점을 맞춰야한다. 단위테스트가 아닌 모든 테스트가 통합테스트에 해당한다. (단위테스트 = 단일 동작 단위를 검증하고, 빠르게 수행하고, 다른 테스트와 별도로 처리한다) # 다시 보는 테스트 피라미드 단위 테스트 - 유지보수성, 피드백 속도가 우수..

단위 테스트 4-7장 (Part 2. 개발자에게 도움이 되는 테스트 만들기) 내용 정리 4장 좋은 단위 테스트의 4대 요소 # 좋은 단위 테스트의 네 가지 특성 - 회귀 방지 - 리팩터링 내성 - 빠른 피드백 - 유지 보수성 1) 첫번째 요소: 회귀 방지 회귀 방지는 테스트가 얼마나 버그(회귀)의 존재를 잘 나타내는 지에 대한 척도다. 회귀 방지 지표에 대한 테스트 점수가 얼마나 잘 나오는 지 평가하려면 테스트 중에 실행되는 코드의 양 / 코드 복잡도 / 코드의 도메인 유의성 을 고려해라. 단순한 코드를 다루는 테스트는 회귀 오류가 많이 생기지 않는다. 기반 코드에 실수할 여지가 많지 않다면 테스트는 회귀를 나타내지 않을 것이기 때문 이다. 복잡한 비즈니스로직을 다루는 테스트가 더 좋다. 2) 두번째 요..

단위 테스트 1~3장 (Part 1. 더 큰그림) 내용을 기반으로 하고 있습니다. 1장 단위테스트의 목표 # 단위테스트 현황 논쟁은 '단위 테스트를 작성해야하는가?' 에서 '좋은 단위 테스트를 작성하는 것은 어떤 의미인가?' 로 바뀌었다. # 단위테스트의 목표 - 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것 지속가능한 프로젝트 성장을 위해서는 고품질 테스트에만 집중해야한다. (사람들은 종종 테스트가 많으면 많을 수록 좋다고 생각한다. 하지만 그렇지 않다. 코드는 자산이 아니라 책임이다. 코드가 많아질 수록, 소프트웨어 내의 잠재적인 버그에 노출되는 표면적이 더 넓어지고 프로젝트 유지비가 증가한다.) 테스트는 코드의 단위가 아니라 동작의 단위. 즉 문제 영역에 의미가 있는 것. 이상적으로는 ..

단위 테스트 3장 내용을 기반으로 하고 있습니다. [ 저자가 생각하는 단위테스트 네이밍 안티패턴 ] 1. 엄격한 명명구조 가장 유명하지만 가장 도움이 되지 않는 방법 중 하나가 다음과 같은 관습이다. [테스트 대상 메서드]_[시나리오]_[예상결과] - 테스트 대상 메서드: 테스트 중인 메서드의 이름 - 시나리오: 메서드를 테스트하는 조건 - 예상결과: 현재 시나리오에서 테스트 대상 메서드에 기대하는 것 동작 대신 구현 세부사항에 집중하게끔 부추기기 때문에 분명히 도움이 되지 않는다. 간단하고 쉬운 영어 구문이 훨씬 더 효과적이다. 예를들어 public class CalculatorTests { public void Sum_of_two_numbers() { ... // when double result =..

회사에서 TDD 관련 외부세션을 듣다가 '서비스가 안티패턴' 이라는 말을 들었다. 왜 안티패턴일까..? 머리에 궁금증이 남아있었는데 클린아키텍처 27장('크고 작은 모든' 서비스들) 을 읽으며 이유를 알게 되었다. 그래서 정리! (참고로 책을 쭉 이끌어온 저자의 맥락을 이 요약글에 다 담을 수 없으니.. 책을 읽어보시는 것을 추천드립니다.) [1] 서비스 아키텍처? 서비스의 이점? 서비스 지향 '아키텍처' 와 마이크로서비스 '아키텍처' 는 최근에 큰 인기를 끌었다. 그 이유는 다음과 같다. - 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. // 결합 분리 - 서비스를 사용하면 개발과 배포 독립성을 지원하는 것 처럼 보인다. // 개발 및 배포 독립 둘다 일부만 맞는 말이다. 뒤에서 살펴..

[1] 서론 업무로 모듈화를 진행하고 있는데, cyclic dependency가 생각보다 많았다,,, 폴더 구조일 때는 편하게 이곳저곳 다 참조하고 있던 코드들이 모듈 구조로 바뀌니 그제야 아픈 곳을 드러내기 시작했다.. 22장 > 클린아키텍쳐 에 나오는 이 내용을 알고 있었으나.. 소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다. 내부의 원에 속한 요소는 외부의 원에 속한 어떤 것도 알지 못한다. 특히 내부의 원에 속한 코드는 외부의 원에 선언된 어떤 것에 대해서도 그 이름을 언급해서는 절대 안된다. 이것을 지키려면 수정범위가 많으니까,,, 적당히... 타협해도 되지 않을까....?.... 내부의 원도.... 외부의 원을.... 조금... 알 수...있게..... 그럼...양방향.....

클린아키텍처 11장 DIP - 의존성 역전원칙 을 읽다가 Abstract Factory 에 대해 여러 고민이 들어서 기록! [1] 책 내용 객체를 생성하려면 해당 객체를 구체적으로 정의한 코드에 대해 소스 코드 의존성이 발생하게 된다. 이런 의존성을 처리하기 위해 추상 팩토리를 사용한다. 예를들어 Application은 ConcreateImpl 에 대한 소스 코드 의존성을 만들지 않기 위해 ServiceFactory 인터페이스의 makeSvc 메소드를 호출하고 ServiceFactoryImp 구현체가 ConcreateImpl 의 인스턴스를 생성한 후 Service 타입으로 반환한다. 곡선은 아키텍쳐 경계를 뜻하는데, 구체적인 것들로부터 추상적인 것들을 분리한다. [2] 경험 + 구글링 보통 Factory..

마틴 파울러 - 리팩터링 (2판) 의 12장 - 상속 다루기 중 좋았던 것들 기록 ✏️✏️ 12.6 타입 코드를 서브클래스로 바꾸기 (Replace Type Code with Subclasses) 보통 열거형, 문자열, 숫자 등의 타입 코드를 쓴다. 타입코드만으로도 특별히 불편한 상황은 별로 없지만 그 이상의 무언가가 필요할 때가 있다. 여기서 '그 이상' 이라 하면 바로 서브클래스를 가리킨다. 서브클래스는 두 가지 면에서 특히 매력적이다. 1. 조건에 따라 다르게 동작하도록 해주는 다형성을 제공 (타입 코드에 따라 동작이 달라져야하는 함수가 여러 개일 때 특히 유용) 2. 특정 타입에서만 의미가 있는 값을 사용하는 필드나 메서드가 있을 때 (필요한 서브클래스만 필요한 필드를 가지도록 하여 더 명확) 이..

마틴 파울러 - 리팩터링 (2판) 의 11장 내용 중 좋았던 것들 기록 ✏️✏️ 11.4 객체 통째로 넘기기 객체를 통째로 넘기면 - 변화에 대응하기 쉽다. - 매개변수 목록이 짧아져서 일반적으로 함수 사용법을 이해하기 쉬워진다. 하지만 함수가 객체 자체에 의존하기를 원치 않을 때는 이 리팩토링을 수행하지 않는다. 특히 객체와 함수가 서로 다른 모듈에 속한 상황이면 특히 더 그렇다. 어떤 객체로부터 값 몇 개를 얻은 후 그 값들로만 무언가를 하는 로직이 있다면 그 로직을 객체 안으로 집어넣어야함을 알려주는 악취로 봐야한다. ==> '객체 통째로 넘기기 vs 객체에서 값 몇개를 꺼내 파라미터로 넘기기'는 개발하며 자주 고민되는 이슈이다. 나도 객체와 함수가 서로 다른 모듈에 속해있는 경우 통째로 넘기기를 ..

마틴 파울러 - 리팩터링 (2판) 의 10장 내용 중 좋았던 것들 기록 ✏️✏️ 10.4 조건부 로직을 다형성으로 바꾸기 조건부 로직(특히 switch문)을 다형성으로 바꾸는 것은 오브젝트에서도 많이 나온 내용이다. 어디서부터 시작할 지 막막할 수 있는 리팩토링인데, 리팩터링 과정을 절차화해주셔서 진행하기 쉽게 해주신 게 좋았다. [ 절차 ] (아래 절차는 책이랑 다르게 제가 순서를 조금 수정한 부분이 있습니다!) 1단계 다형적 동작을 표현하는 클래스들이 아직 없다면 만들어준다. 조건부 로직 함수를 슈퍼클래스로 옮긴다. (조건부 로직이 온전한 함수로 분리되어 있지 않다면 먼저 함수로 추출한다) 2단계 적합한 인스턴스를 알아서 만들어 반환하는 팩터리 함수도 함께 만든다. 호출하는 코드에서 팩터리 함수를 사..