싱글톤 패턴은 디자인 패턴 중 하나로, 특정 클래스의 인스턴스가 전체 시스템에서 오직 '한 개'만 생성되도록 보장하는 것을 목적으로 한다. 이 패턴을 사용하면 전역 변수를 사용하지 않고도 특정 클래스의 인스턴스에 대한 전역 접근이 가능하며, 이를 통해 코드의 유연성과 유지 보수성을 높일 수 있다. 예를 들어 로깅 라이브러리를 구현할 때, 여러 곳에서 로그를 출력하게 된다고 해보자. 이때 각각의 로그 출력 메서드마다 로깅 객체를 생성된다면 시스템 리소스의 낭비가 발생할 수 있다. 따라서, singleton 패턴을 사용하여 로깅 객체를 전체 시스템에서 한 번만 생성하도록 보장할 수 있다.

 

다음은 Java로 나타낸 싱글톤 패턴의 예제 코드다.

public class Logger {
    // 인스턴스 변수
    private static Logger instance = null;
    
    // 생성자를 private로 만들어 다른 클래스에서 인스턴스 생성을 막는다.
    private Logger() {}
    
    // getInstance() 메소드를 통해 전역적으로 유일한 인스턴스를 반환한다.
    public staitc Logger getInstance() {
    	if(instance == null) {
        	instance = new Logger();
        }
        return instance;
    }
    
    // 로그를 출력하는 메소드
    public void log(String message){
    	System.out.println(message);
    }
}

// Logger 인스턴스를 가져와서 로그를 출력한다.
Logger logger = Logger.getInstance();
logger.log("Hello, world!");

 

위 예시에서, Logger 클래스는 생성자를 private으로 만들어 다른 클래스에서 인스턴스를 생성할 수 없도록 했다. 대신, getInstance() 메서드를 통해 전역적으로 유일한 인스턴스를 반환하도록 했다. 이렇게 함으로써, Logger 클래스의 인스턴스는 오직 한 개만 생성될 수 있도록 보장할 수 있다. 위의 코드에서 Logger 클래스의 인스턴스를 가져와서  로그를 출력하게 되는데, 이때 getInstance() 메서드를 사용해 전역적으로 유일한 인스턴스를 가져오도록 했다. 따라서, Logger 클래스의 인스턴스는 오직 한 개만 생성되며, 로그를 출력하는 코드에서는 이를 공유하여 사용할 수 있다.

 

 

Singleton 패턴의 장점은 다음과 같다,.

 

1. 전역적인 인스턴스

singleton 패턴은 전역적으로 하나의 인스턴스만을 유지하므로, 모든 코드에서 해당 인스턴스에 대해 접근할 수 있다.

 

2. 리소스 절약

객체를 여러 번 생성하지 않으므로, 시스템 자원을 절약할 수 있다.

 

3. 데이터 공유

하나의 인스턴스를 공유하기 때문에, 데이터를 공유하거나 데이터를 수정하기 용이하다.

 

 

Singleton 패턴의 단점은 다음과 같다.

 

1. 테스트가 어려움

전역적인 인스턴스를 사용하므로, 테스트할때 다른 인스턴스를 사용할 수 없어 테스트가 어려울 수 있다.

 

2. 결합도 증가

다른 객체와의 결합도가 높아지므로, 유지보수가 어려워질 수 있다.

 

3. 멀티스레딩 이슈

싱글톤 패턴을 사용할 때, 멀티스레드 환경에서 동시에 인스턴스를 생성하려는 이슈가 발생할 수 있다.

 

 

그럼 Singleton 패턴을 언제 사용하는 것이 좋을지에 대해 알아본다면 다음이 있다.

 

1. 전역적으로 사용되는 객체

어떤 객체가 전체 시스템에서 단 하나만 존재해야할 때 사용한다.

 

2. 자원의 낭비를 방지해야 할 때

객체를 여러 개 생성할 필요가 없으므로, 시스템 자원의 낭비를 방지하기 위해 싱글톤 패턴을 사용한다.

 

3. 공유 자원

싱글톤 패턴을 사용하여 전역적으로 인스턴스를 공유할 수 있다. 예를 들어, 로깅이나 설정 정보를 공유하는 경우에 사용하기 적합하다.

 

4. 동일한 객체의 상태를 유지할 때

싱글톤 패턴을 사용해 하나의 인스턴스를 사용하면, 해당 객체의 상태를 유지할 수 있다.

 

 

 

Singleton 패턴은 다음과 같은 특징을 가지고 있다.

  1. 클래스 내부에서 인스턴스를 생성하고, 외부에서 직접 생성할 수 없도록 생성자를 private으로 선언한다.
  2. 유일한 인스턴스에 접근하기 위한 public static 메서드를 제공한다.
  3. 인스턴스가 이미 생성되어 있으면 해당 인스턴스를 반환하고, 생성되어 있지 않으면 인스턴스를 생성한 후 반환한다.

 

다음은 TypeScript를 사용한 싱글톤 패턴 예제 코드다.

class Singleton {
    private static instance: Singleton;
    
    // 생성자를 private으로 선언해 외부에서 인스턴스 생성을 막는다.
    private constructor() {}
    
    // 인스턴스를 반환하는 메서드를 static으로 선언하여 전역적으로 접근할 수 있게한다.
    public static getInstance(): Singleton {
        if(!Singleton.instance) {
            Singleton.instance = new Singleton();
        }
        return Singleton.instance;
    }
    
    public doSomething(): void {
    	console.log("Singleton instance is doing something...");
    }
}

// Singleton 클래스의 인스턴스를 생성할 수 없다.
// const instance = new Singleton(); // Error: 'constructor' is private.

// Singleton 클래스의 인스턴스는 getInstance 메서드를 통해서만 생성한다.
const instance1 = Singleton.getInstance();
const instance2 = Singleton.getInstance();

console.log(instance1 === instance2); // true

instance1.doSomething(); // "Singleton instance is doing something..."
instance2.doSOmething(); // "Singleton instance is doing something..."

 

위 코드에서 Singleton 클래스를 정의하고, private 생성자를 선언해 외부에서 인스턴스 생성을 막는다. 인스턴스를 반환하는 getInstance 메서드를 static으로 선언해 전역적으로 접근할 수 있도록 한다. 이때, 인스턴스가 생성되어 있지 않은 경우에만 인스턴스를 생성하고 반환하게 한다.

실제로 인스턴스를 사용할 때에는 getInstance 메서드를 호출해 인스턴스를 생성하고, 반환된 인스턴스에서 메서드를 호출한다. 인스턴스는 한 번 생성되면 전역적으로 유지되므로, 여러 곳에서 같은 인스턴스를 사용할 수 있다.

반응형

리액트에서 테스트를 위해서 많이 사용하는 도구 중 하나인 React Testing Library에 대한 포스트입니다.

테스트에 사용되는 라이브러리들이 많으니 각자 본인에게 맞는 것을 활용해 공부하며 적용해 보는 것이 좋을 것 같습니다.

아래에 리액트 공식 사이트에서 사용되는 테스트 유틸 및 라이브러리 예시를 확인해보세요.

  • Enzyme: React를 위한 JavaScript 테스트 유틸.
  • Jest: React를 포함한 JavaScript 테스트 프레임워크.
  • react-testing-library: 가벼운 React DOM 테스트 유틸.
  • React-unit: React를 위한 가벼운 단위테스트 라이브러리.
  • Skin-deep: 얕은 렌더링을 지원하는 React 테스트 유틸.
  • Unexpected-react: React 컴포넌트와 이벤트를 발생시켜주는 플러그인.

설치

yarn add @testing-library/react @testing-library/jest-dom

npm install --save react-testing-library @testing-library/jest-dom

npm 또는 yarn을 이용해 react-testing-library를 설치한다. react-testing-library@testing-library/react 로 변경되었으니 주의!

jest-dom@testing-library/jest-dom 으로 변경됐다고 한다.

react-testing-library는 '사용자 관점'에서 테스트를 진행한다. 보통 Enzyme를 이용한 테스트 방식은 상태값, 상태 변수에 대해 테스트를 한다. 하지만 전자는 상태 관리는 컴포넌트의 구현 세부사항일 뿐이다. 즉, 상태 변수가 언제든 다른 컴포넌트로 옮겨지거나, react에서 vue.js로 바뀌더라도 테스트에는 문제가 없어야한다.

다양한 쿼리

  • getBy* 쿼리 (ex. getByTestId, getByText, getByRole): 이 함수들은 동기적(synchronous)이며 그 요소가 현재 DOM 안에 있는지 확인한다. 즉, 현재상태만 확인한다. 그렇지 않으면 에러를 발생시킨다.
  • findBy* 쿼리 (ex. findByText): 이 함수들은 비동기적(asynchronous)이다. 그 요소를 찾을 때까지 일정 시간(기본 5초)을 기다린다. 만약 그 시간이 지난 후에도 요소를 찾을 수 없으면 에러를 발생시킨다.
  • queryBy* 쿼리: 이 함수들은 getBy* 처럼 동기적이다. 하지만 요소를 찾을 수 없어도 에러를 발생시키지 않는다. 단지 null 값을 리턴한다.

테스트 디버깅하기

render(<SomeComponent />);
screen.debug(); //원하는 실행 지점에서 DOM트리를 console에 출력해, 디버깅할 수 있다.

screen.debug() 는 브라우저의 개발 도구처럼 편리하고 상호작용적이진 않지만, 테스트 환경에서 어떤 일이 일어나고 있는지 확실히 알 수 있도록 도와준다.

const link = screen.getByRole('link', { name: /how it works/i });
screen.debug(link);

위와 같이 debug 함수에 파라미터를 전달하면 해당 요소만을 콘솔에 출력해준다.

Mocking

  • jest.fn: Mock a function
  • jest.mock: Mock a module → 자동적으로 모듈의 모든 함수를 mocking 해준다.
  • jest.spyOn: Spy or mock a function → 마찬가지로 모든 함수를 mocking 해주면서, 원래의 함수를 다시 복원할 수도 있다.

가장 기본적인 사용 방식은 함수를 mock 함수로 재할당하는 것이다. 재할당 된 함수가 쓰이는 어디서든지 mock 함수가 원래의 함수 대신 호출 될 것이다.

예시
  1. jest.fn() mocking
// app.js
import * as math from './math.js';

export const doAdd      = (a, b) => math.add(a, b);
export const doSubtract = (a, b) => math.subtract(a, b);
export const doMultiply = (a, b) => math.multiply(a, b);
export const doDivide   = (a, b) => math.divide(a, b);
// math.js
export const add      = (a, b) => a + b;
export const subtract = (a, b) => b - a;
export const multiply = (a, b) => a * b;
export const divide   = (a, b) => b / a;
// app.test.js

import * as app from "./app";
import * as math from "./math";

math.add = jest.fn();
math.subtract = jest.fn();

test("calls math.add", () => {
  app.doAdd(1, 2);
  expect(math.add).toHaveBeenCalledWith(1, 2);
});

test("calls math.subtract", () => {
  app.doSubtract(1, 2);
  expect(math.subtract).toHaveBeenCalledWith(1, 2);
});

  1. jest.mock() mocking
jest.mock('./math.js');

위의 코드로 mocking하는 것은 본질적으로 아래 코드처럼 하는거랑 같다.

export const add      = jest.fn();
export const subtract = jest.fn();
export const multiply = jest.fn();
export const divide   = jest.fn();
// app.test.js

import * as app from "./app";
import * as math from "./math";

// Set all module functions to jest.fn
jest.mock("./math.js");

test("calls math.add", () => {
  app.doAdd(1, 2);
  expect(math.add).toHaveBeenCalledWith(1, 2);
});

test("calls math.subtract", () => {
  app.doSubtract(1, 2);
  expect(math.subtract).toHaveBeenCalledWith(1, 2);
});
반응형

 

모든 npm 패키지에는 보통 프로젝트 루트에 package.json이라는 파일이 들어 있다. 이 파일에는 프로젝트와 관련된 다양한 메타데이터가 저장되어 있다. 이 파일은 프로젝트의 종속성(dependencies)을 처리할 뿐만 아니라 프로젝트를 식별할 수 있는 정보를 npm에 제공하는 데 사용된다. 또한 프로젝트 설명, 특정 배포의 프로젝트 버전, 라이선스 정보, 구성 데이터 등과 같은 다른 메타데이터도 포함할 수 있으며, 이 모든 메타데이터는 npm과 패키지의 최종 사용자에게 필수적일 수 있다. package.json 파일은 일반적으로 Node.js 프로젝트의 루트 디렉터리에 위치한다.

 

 

Node.js 자체는 패키지의 다음의 두 필드만 인식한다.

{
  "name" : "프로젝트 이름",
  "version" : "0.0.0",
}

 

- name : 해당 프로젝트의 이름을 작성해주면 된다.

- version : 올바른 버전의 패키지가 설치되고 있는지 확인하기 위해 npm에서 사용한다.

일반적으로 major.minor.patch의 형태를 취하는데, major, minor, patch는 major, minor, patch는 매 신규 출시 후 증가하는 정수다.

 

 

 

{
  "name" : "underscore",
  "description" : "JavaScript's functional programming helper library.",
  "homepage" : "http://documentcloud.github.com/underscore/",
  "keywords" : ["util", "functional", "server", "client", "browser"],
  "author" : "Jeremy Ashkenas <jeremy@documentcloud.org>",
  "contributors" : [],
  "dependencies" : [],
  "repository" : {"type": "git", "url": "git://github.com/documentcloud/underscore.git"},
  "main" : "underscore.js",
  "version" : "1.1.6"
}

 

 

보시다시피 프로젝트의 설명(description) 및 키워드(keywords) 필드가 있다. 이것은 당신의 프로젝트를 찾은 사람들이 그것이 무엇인지 단 몇 마디 말로 이해할 수 있게 해준다. 작성자(author), 기고자(contributors), 홈페이지(homepage), 리포지토리(repository) 분야는 모두 프로젝트에 기여한 사람들을 신용하고, 작성자/유지인에게 연락하는 방법을 보여주며, 추가 참조를 위한 링크를 제공하는 데 사용할 수 있다.

 

main 필드에 나열된 파일은 라이브러리의 주요 진입점이며, 누군가 require(<library name>) 으로 실행하려면 require(<package.json:main>) 식으로 호출해 라이브러리를 사용할 수 있다. dependencies 필드는 npm에서 사용할 수 있는 프로젝트의 모든 dependencies을 나열하는 데 사용된다. 누군가가 npm을 통해 당신의 프로젝트를 설치하면, 나열된 모든 dependencies 또한 설치될 것이다. 또한 다른 사용자가 프로젝트의 루트 디렉토리에서 npm 설치를 실행하면 ./node_modules에 모든 dependencies을 설치하게 된다.

 

devDependencies 필드를 package.json에 추가할 수도 있다. 이러한 종속성은 정상 작동에 필요한 것이 아니라 프로젝트를 패치하거나 수정하려는 경우 필수/권고 사항이다. 예를 들어, 테스트 프레임워크를 사용하여 장치 테스트를 작성한 경우 devDependency 필드에 사용한 테스트 프레임워크를 넣는 것이 적절할 것이다. 프로젝트의 devDependencies를 설치하려면 npm 설치를 사용할 때 --dev 옵션을 넣으면된다.

반응형

+ Recent posts