728x90 반응형 source-code/software41 싱글톤 패턴 단위 테스트를 작성하는 3가지 방법 Backgrounds싱글톤 패턴(Singleton Pattern)이란?싱글톤 패턴은 애플리케이션 내에서 특정 클래스의 인스턴스가 단 하나만 생성되도록 보장하는 디자인 패턴입니다. 데이터베이스 연결, 설정값 관리, 공통 서비스 제공 등 애플리케이션 전역에서 공유되어야 하는 리소스를 관리할 때 자주 사용됩니다.class Singleton { private static instance: Singleton | null = null; private constructor() {} static getInstance(): Singleton { if (!this.instance) { this.instance = new Singleton(); } return this.instance; }}.. 2024. 11. 19. 소프트웨어 장인 정신 이야기 (5) 2부. 기준기준은 기본적인 '기대 수준'이다. 이는 우리가 지켜야 한다고 정한 기준선이다. (...) 기준을 능가하는 건 상관없지만 절대 그에 못 미쳐서는 안 된다. 9장. 생산성여러분의 CTO로서 나는 생산성에 있어 몇 가지를 기대한다.- 나는 절대 똥덩어리를 출시하지 않기를 기대한다- 나는 낮은 수정 비용을 기대한다- 나는 우리가 언제나 준비되어 있기를 기대한다- 나는 안정적인 생산성을 기대한다 10장. 품질여러분의 CTO로서 나는 품질에 있어 몇 가지를 기대한다.- 나는 지속적인 개선을 기대한다- 나는 두려움을 이기는 능력을 기대한다- 나는 극한의 품질을 기대한다- 나는 우리가 QA에게 떠넘기지 않기를 기대한다- 나는 현실적으로 자동화 가능한 모든 테스트가 '자동화되기를' 기대한다 자동화 테스트와 .. 2024. 5. 25. 소프트웨어 장인 정신 이야기 (4) 5장. 리팩터링더보기리팩터링은 동작을 바꾸지 않으면서 코드를 연속적으로 조금씩 바꿔서 소프트웨어의 구조를 개선하는 것인데, 각 변경을 마무리할 때마다 포괄적인 테스트 묶음을 통과시킴으로써 동작이 바뀌지 않았음을 증명한다.여기서 핵심은→ 1) 리팩터링은 동작을 보존한다 2) 개별 리팩터링은 작다. 디버깅이 필요하지 않을 만큼! 기본 도구이름 바꾸기무언가의 정확한 이름을 찾는 일은 연속적이고 반복적인 개선 과정인 경우가 많다. 정확한 이름을 추구하는 일을 두려워하지 말라. 프로젝트가 아직 초기일 때 가능한 자주 이름을 개선하라. 좋은 이름 짓기는 정말 어렵다!!이때 기억하면 좋을 교훈은 → 연속적이고, 반복적인 개선을 통해 최선의 이름을 찾을 수 있다는 것.따라서 변경을 두려워하지 말아야 한다. 지속적으로 .. 2024. 5. 23. 소프트웨어 장인 정신 이야기 (3) 4장. 테스트 설계데이터베이스 테스트하기데이터베이스를 테스트할 때 첫 번째 규칙은 다음과 같다. 데이터베이스를 테스트하지 말라.(...) 두 번째 규칙은 다음과 같다. 데이터베이스를 비즈니스 규칙과 분리하라. 결국 핵심은, 비즈니스 규칙과 그 이외의 요소들을 명확히 분리 하는 것! 이를 위해 인터페이스(예제에서는 Gateway)를 만들어해당 인터페이스를 구현하는 클래스가 실제 데이터베이스에서 필요한 기능을 수행하도록 작성해야 한다. 이를 통해 인터페이스 경계 너머(비즈니스 로직)에서는SQL도, ORL 프레임워크도, 데이터베이스 API도, 데이터베이스 스키마도 알 필요가 없으며,오직 의존 중인 인터페이스가 정의한 결괏값(비즈니스 객체)에만 신경 쓸 수 있게 된다.→ 비즈니스 로직을 테스트할 때는, 스텁이나.. 2024. 5. 20. 소프트웨어 장인 정신 이야기 (2) 2024.05.07 - [source-code/software] - 소프트웨어 장인 정신 이야기 (1)3장. 고급 테스트 주도 개발단계마다 테스트는 더욱더 제한적이고 구체적으로 바뀌는 반면, 제품 코드는 점점 더 일반화된다. 이 과정은 제품 코드가 너무 일반적이어서 실패하는 테스트를 더 이상 생각해 낼 수 없을 때까지 계속된다. 그러면 문제가 모두 풀린 것이다. 복잡한 문제일 수록, 단순한 공리(실패하는 테스트 코드)에서 출발해야 한다.한 번에 한 단계씩, 제품 코드를 구현하고, 리팩터링 하고, 다음 테스트 케이스를 작성해야 한다. 하지만... 모든 경우에 이러한 주기를 적용하는 게 어렵지 않을까?가장 대표적인 예시가 → 요구사항이 너무 복잡해서, 한 번에 모든 구현을 작성하지 않으면 테스트 케이스가 통.. 2024. 5. 9. 소프트웨어 장인 정신 이야기 (1) 1장. 장인 정신...이 연대표를 항공학 연대표와 비교해 보자. 비슷한 점을 찾을 수 있는가? 이론의 단계적인 발전, 마니아들이 성급한 도전과 실패, 역량의 단계적인 발전이 보이는가? 우리가 무엇을 하는지도 몰랐던 수십 년의 기간이 보이는가?...오늘날의 항공기 조종사들만큼이나 자기 기술을 깊이 이해하는 프로그래머를 양성해 왔는가? 분명히 장인이 필요한데 우리에게는 장인이 있는가? 항공학 역사를 소개하며, 장인 정신의 필요성을 강조한 구문이 굉장히 인상 깊었다. 프로그래밍 역시 (항공학과 유사하게) 인류의 삶에 밀접하게 연관되어 있으며빠른 속도로 발전했고명확한 장인 정신이 구축되지 않은 상태로 사용되었으며이로 인해 불필요한 시행착오들이 반복되고 있다 는 것!즉... 오늘날의 항공학이 '안전하게 비행기를 .. 2024. 5. 7. [jest] jest dom을 통한 DOM 객체 동작 테스트 하기 Backgrounds 현재 개발 중인 서비스에서는 사용자가 생성한 데이터를 통해 웹 페이지에서 특정 요소(HTMLElement)를 조회하는 기능을 제공하고 있습니다. 이때 해당 요소를 찾는 알고리즘이 제법 복잡하고 예외 케이스가 많이 발생해, 코드를 수정할 때마다 고객사 페이지에 직접 접속해 정상 동작 여부를 확인하는 불편함이 존재했습니다. 그리고 이로 인해 1) 개발 소요 시간 증대 2) 적극적인 리팩토링 어려움 (수정이 발생하면, 기존 잘 되던 케이스가 안될 것이라는 두려움) 과 같은 문제들이 발생했습니다. Solutions 최선의 방안은 모든 고객사 페이지를 자동으로 크롤링하면서, 로직이 정상 동작하는지 확인하는 것이겠으나... 하루아침에 이 정도의 자동화 테스트를 도입하기엔 현실적인 무리가 있었습.. 2024. 4. 10. 단위 테스트 - 고전파와 런던파, 그리고 개인적인 견해 Backgrounds사내 package를 개발하며 테스트 코드를 작성하던 도중, 이런 일이 있었습니다. 입력받은 데이터를 서비스 내부 정책에 따라 필터링하는 모듈이 존재했고, 해당 모듈은 내부 정책 관련 로직을 처리하는 다른 모듈을 의존성으로 주입받고 있었습니다.class Module { filterPoliciy: Policy constructor (filterPoliciy: Policy) { this.filterPoliciy = filterPoliciy } filter(data:Data): Data | null { // 해당 메서드 내부적으로 Policy interface 사용 ...this.filterPoliciy.isIdExist() } } 아래와 같은 형태로 테스트 코드를 작성했습니다.descri.. 2024. 3. 28. 추상 팩토리(Abstract Factory) 패턴 추상 팩토리 패턴이란? 추상 팩토리는 객체의 인스턴스 생성에 관여하며, 클래스 정의와 객체 생성 방식을 구조화/캡슐화하는 생성 패턴의 한 종류이다. 서로 연관되거나 의존적인 객체의 집합을 생성하기 위한 인터페이스를 제공해 구체적 클래스에 의존하지 않음으로써, 새로운 객체 생성 로직의 추가나 변경 사항에 쉽게 대응할 수 있다. 사용 예제 다음과 같은 요구 사항이 있었다. 1. DB에 Template이라는 table이 존재한다. (사용자가 입력한 여러 데이터로 구성) 2. 각 Template은 type이라는 속성을 갖는다. 해당 속성을 통해 Template의 종류를 구분한다. ex) modal, tool-tip... 3. 각 Template은 type에 따라 각기 다른 형태의 HTMLElement를 갖는다 .. 2023. 11. 8. 이전 1 2 3 4 5 다음 728x90 반응형