Testing

해피데빙·2023년 1월 30일
0

줌 : https://zuminternet.github.io/zum-comment-component/
이외 : https://techblogposts.com/?search
vue 테스팅 핸드북 : https://lmiller1990.github.io/vue-testing-handbook/ko/vuex-actions.html#%EC%95%A1%EC%85%98-%EC%83%9D%EC%84%B1%ED%95%98%EA%B8%B0

출처 : 프로그래머 이규원의 '현실 세상의 TDD: 안정감을 주는 코드 작성 방법' 강의

TDD

  • 테스트 주도 개발
  • 제품의 기능 구현을 위한 코드와 별개로 해당 기능이 정상적으로 움직이는지 검증하기 위한 테스트 코드 작성
  • 테스트 실패 시 통과 위해 최소한으로 코드 개선
  • 최종적으로 테스트에 성공한 코드를 리팩토링
  • 반복 테스트를 이용한 소프트웨어 방법론
  • 자동화된 테스트 코드를 작성한 후 테스트를 통과하기 위한 코드를 개발하는 방식

테스트 기법의 종류

  1. Unit Test

  2. Integration Test

  3. Functional Test

  4. 소프트웨어 테스팅이란
    1) 정의
    2) 테스트 타입
    3) 테스트 방법
    4) 테스트 접근 방법
    5) 테스트 레벨

  5. 소프트웨어란?

  • 컴퓨터에 내리는 명령들 또는 프로그램
  • 두 가지로 분류 할 수 있다
    1)system software
  • os (operating system) 등 기능들

2)application software

  • 구체적인 행동을 하는 프로그램들 ex. 게임, 워드 등

3)이외

  • middleware
  • driver software
  • programming software
  1. 테스팅(software testing)이란?
  • 애플리케이션이 구체적인 요구 사항들을 충족했는지 확인하기 위해 사용
  • 양질의 상품을 만들기 위해 결함을 확인하고 수정하는 과정

테스팅 타입
1. manual testing
2. automation testing : 수동 테스트가 지닌 한계를 보완하기 위해 등장한 도구. 사람이 직접 테스트하지 않고

  • 더 많은 코드 작성 필요 : 운영 코드 테스트 위해 별도의 코드 추가 작성 필요
  • 테스트 코드의 작성과 관리가 프로그래머 개인의 역량에 달려 있어 업무 자체가 허들
  • 테스트에 드는 비용이 매우 낮아진다
  • 휴먼 에러의 가능성도 줄어든다 : 신뢰도 상승

인수 테스트

  • 배치된 시스템을 대상으로 검증하는 방식
  • 클라이언트가 의뢰한 소프트웨어를 최종적으로 사용할 수 있는 수준인지 점검하는 테스트
  • 전체 시스템의 이상 여부가 없는지 확인
  • 사용자 관점으로 체크하기 때문에 신뢰도가 높은 테스트 방법

비용이 매우 높다 : 작성비용/관리비용/실행비용
프로그래머 입장에서 받을 수 있는 피드백의 질이 낮음
: 현상은 드러나지만 원인은 단번에 알려주지 못하기 때문에

단위 테스트

  • 인수 테스트의 단점을 보완하는 검증 방식
  • 시스템의 일부(하위 시스템)을 대상으로 기능을 검증하는 테스트

장점

  • 전체 시스템을 만들어놓고 하는 게 아니라서 비용이 상대적으로 낮음 : 작성비용/관리비용/실행비용
  • 단위 안에 버그가 있다는 걸 상대적으로 자세히 알 수 있다 : 문제 해결을 위해 필요한 피드백을 적절하게 알 수 있다
    단점
  • 전체 시스템의 이상 여부를 판단하는 신뢰도는 낮아진다 : 단위 테스트에서 문제가 없다고 판단되어도 전체 시스템이 유기적으로 연결될 때 오류가 날 수도 이씩 때문

testing methods
testing approaches
black-box testing

definition of software tesing in software engineering
: process of analyzing a software product or system to examining a software product or system to determine whether it satisfies or fails to satisfy established conditions (i.e., defects). The testing process evaluates the software products characteristics for requirements such as missing requirements, bugs, or errors in order to evaluate its reliability, security, and performance.

소프트웨어 제품이나 시스템을 분석해서 성립된 조건들을 충족하는지 확인하는 과정
부족한 요건들, 버그들, 에러 등을 확인한다.

  1. 테스팅이 필요한 이유

  2. cost-effectiveness
    복잡한 시스템에서 결함이 없을 것을 기대하기는 어렵다
    너무 복잡하니까
    결함을 발견하고 수정하기 어렵다
    한 버그를 수정하면서 다른 버그를 만들 수도 있다

  3. customer satisfaction

  4. security

  5. product quality

  6. manual Testing
    :뭐가 제대로 작동하고 작동하지 않는지 확ㅇ니하기 위해 직접 테스트를 하는 방법
    :요구사항 문서대로 확인하는 것 / 테스터가 유저의 관점으로 소프트웨어를 점검하는 거
    ex. Testpad

  7. automation testing
    : using automation testing tools to control the execution of tests and compare the results against expected outcomes and to find the defects
    : testers execute the test scripts and generate the test results automatically by using automation tools
    ex. selenium, testRigor, katalon studio

SW Testing 필요성

ex. 싸이 강남스타일 12/1일 21억뷰 -> -21억뷰로 음수로 변경하는 버그 발생
32비트로 개발이 되었는데 integer의 최대값이 넘어가서 음수로 바뀌는 문제가 생김
자동차도 기계나 전자만큼이나 소프트웨어가 중요해짐
매년 연초마다 진행되는 국제 가전쇼를 위해 자동차 도메인에 있는 사람들을

테스트 코드와 TDD

  • 기능 구현 코드를 작성
  • 제대로 구현했는지 검증하기 위해 테스트 코드를 작성해야 한다

개발자는 기능 구현뿐만 아니라 테스트를 잘 작성해야 한다

What is testing? (sw test)

  • 제품 또는 서비스의 품질을 확인
  • 소프트웨어의 버그를 찾는다
  • 제품이 원하는대로(예상하는 대로) 동작하는지 확인

제품 : 함수, 특정 기능, UI, 성능, API 스펙 등
종류 : unit, integration, function 등
프로레스는 특정한 기능을 수행하는 비즈니스 로직을 가지고 있는 소스코드가 있다면 이에 해당하는 테스트코드를 작성해서 우리의 예상에 맞는지 확인할 수 있어야 한다
특정 상황에서 함수, 특정한 기능, ui, 성능, api 스펙 등을 원하는대로/예상하는 대로 작동하는지 확인

테스트 코드를 통해 모든 테스트를 패스하면 퇴근/ 실패하면 코드에서 어떤 부분이 잘못 되었는지 확인하기

테스트의 포인트는 우리의 예상을

TDD

  • test driven development (테스트 주도 개발)
  • 실패하는 코드를 먼저 작성하고 이에 해당하는 기능을 구현해나가는 방식
  • 개발방법론
    1. 코드를 작성하기 전에 특정 기능에 한해서 기능을 세분화해서 하나의 케이스에 대해 테스트를 작성한다
  1. 기능 구현 전 테스트를 수행한다
  2. 실패한 테스트를 성공할 수 있을 정도의 코드를 작성한다
  3. 다음 기능으로 가서 반복한다
    즉 테스트 코드 작성 -> 테스트 성공 코드 작성 반복
    지금까지 작성했던 테스트코드를 모두 통과하는지 확인하고 리팩토링한다

실패하는 코드를 먼저 작성하는 이유?
1. 요구사항 분석 및 이해가 필요 : 테스트를 통해 요구사항에 대한 명확한 이해 바탕으로 설계 가능, 모든 요구 사항(목표)에 대해 점검 가능
2. 사용자 입장에서 코드를 작성할 수 있다 : 구현보다 인터페이스를 기준으로 코드의 퀄리티를 향상할 수 있다
=> 시스템 전반적인 설계 향상
3. 테스트 - 기능 (개발 집중력 향상 가능)

rewrite the test,
run test,
실패하면 조금

  • 테스트를 통해 리팩토링도 할 수 있다
  • 테스팅이란 무엇 / 언제 작성 / 장점 / 테스트 피라미드
  • ci/cd에서 테스팅의 역할
  • 자바스크립트로 단위 테스트를 작성하는 방법, 테스트를 통한 코드 개선법, 좋은 테스트 코드를 위한 여러가지 원칙들
  • TDD 작성
  • react node에서 사용할 수 있는

우테코
1. TDD란?
창시자 켄트백 : "프로그램을 작성하기 전에 테스트를 먼저 하라!"
테스트코드를 먼저 만들고 실제 프로덕션 코드를 나중에 만드는 개발 방법론

2.레드 그린 리팩터라고 불리는 TDD개발 사이클
1. red : 테스트 실패하는 테스트 코드를 작성
2. green : 테스트를 성공하는 프로덕션 코드를 작성
3. refactor : 프로덕션 코드와 테스트 코드를 리팩토링한다

  1. 왜 사용해야 할까?
  • 변화에 대한 두려움을 줄여준다 (리팩토링이 편하다)
  • 디버깅 시간을 줄여준다
  • 동작하는 문서 역할을 한다
  • 진정한 장점 :
    1) 자연스레 테스트 커버리지가 높아진다 : 나중에 작성해도 높은 건 마찬가지지만 테스트를 먼저 작성하면서 테스트에 대한 우선순위를 높인다.
    2) 오버 엔지니어링 방지 : 필요한 만큼만 코딩을 할 수 있다.
    3) 설계에 대한 피드백이 빠르다 : 변경이 일어나거나 등 이후에 알게 되면 어렵다. 테스트 코드를 작성하는데 복잡하고 잘못된 설계를 가지고 있으면

TDD는 설계 방법론? X
설계 방법론은 좋은 설계를 얻을 수 있어야 한다

  • 높은 응집을 유도하지 않고
  • 단일 책임 원칙과 인터페이스 분리 원칙 위배에 어떤 신호도 주지 않는다
  • 인터페이스 일관성 도출하지 않는다
  • 리팩토링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다

TDD 실패하는 사람이 하는 테스트
이규원님의 okkycon 강연 중 일부

  • 코드가 이루고자 하는 가치나 기능을 테스트하기보다 그 기능을 어떻게 구현하고 있는지를 테스트
  • 결국 테스트 케이스들이 구현체와 결합도가 높아진다
  • 구현체들을 리팩토링하면 결합되어 있는 테스트 케이스들이 모두 깨져버린다
  • 테스트들이 implementation 내부에 존재하는 구현체들을 테스트하고 있다
  • implemetation을 리팩토링하게 되면 테스트들이 모두 깨지게 된다
  • 구현체가 아닌 설계, 즉 인터페이스를 테스트해야 한다
  • 그럼 내부에 있는 구현체를 리팩토링해도 테스트 케이스가 깨지지 않는다

프로그램 전체 테스트
기본적인 단위테스트부터 점점 범위를 넓히면서 테스트한다

  • 인수 : 고객 또는 대리인이 정의되어진 모든 목적에 부합되는지 확인해보고자 하는 검사

  • 부하 : 주어진 단위 시간 동안 어플리케이션이 얼마나 많ㅇ느 요청을 처리할 수 있는지 검사

  • 기능 : 공개된 API의 가장 바깥쪽에 해당하는 코드 검사( controller 호출, security, http)

  • 통합 : 여러 작업 단위가 연계된 워트플로우를 테스트하기 위한 수단 (객체 간, 서비스 간, 시스템 간)

  • 단위
    - 가장 작은 범위인 코드 단위의 테스트

    • 일반적으로 메서드 레벨을 테스트
    • 검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 또는 프로세스
    • unit testing: 테스트 코드가 목적 코드의 완전성을 입증해주기 때문에 테스트 코드 그 자체만으로 주요한 가치가 있다
    • 목적
      1) 문제점 발견 : 각 단위가 정확하게 동작하는지 검사, 문제 발생 시 어느 부분이 잘못되었는지 재빨리 확인할 수 있게 해준다 [프로그램 안정성 증가]
      2) 변경이 쉽다 : 어떻게 코드를 고치더라도 문제점을 금방 파악할 수 있고 수정된 코드가 정확하게 동작하는지 쉽게 알 수 있다
      3) 품질 향상 : 한아ㅢ 단위 테스트가 너무 길거나 복잡해지면 프로덕션코드에서부터 잘못 되었다는 것을 알 수 있다. 리팩토링을 해야 한다는 것을 알 수 있다
      4) 코드의 문서화 (샘플 코드) : 예외 상황, 용도, 의존 관계를 한눈에 파악할 수 잇다
      5) 단위테스트는 배포되는 코드와 일치하므로 항상 최신 사태로 유지된다
    • 좋은 단위 테스트를 만들기 위해 지켜야 하는 규칙
      1) Fast: 테스트가 빠르고 문제를 빨리 찾을 수 있어야 자주 돌릴 수 있기 때문에.
      2) Independent: 독립적으로. 테스트는 서로 의존하면 안된다. 하나가 실패할 때 나머지도 잇따라 실패하게 되니까 원인을 진단하기 어려워지고 후반 테스트가 찾아내기 어렵다
      3) repeatable : 반복 가능하게. 어떤 환경에서도 반복 가능하게 해야 한다. 실제 환경, qa환경, 네트워크가 연결되지 않은 환경 등
      4) self-validating : 자가 검증하는. 성공 또는 실패로 객관적인 평가를 내려줘야 한다. 그게 아니라면 주관적인 수작업이 필요함
      5) timely: 적시에. 테스트를 하려는 실제 코드를 구현하기 직전에 구현해야 한다. 실제 코드 구현 후에 테스트를 만들면 실제 코드가 테스트하기 어렵다는 것을 뒤늦게 발견할 수 있다.

    TDD 이규원
    생각하기 않고 코드를 쓰는 것을 프로세스에서 막아주는 방법론
    실제 업무에서는 필요 없거나 어렵다고 생각하는 이유 : 시간이 너무 많이 걸린다 / 사용했는데 효과가 별로 없더라 (버그가 완전히 사라지지 않는다)
    모든 일들을 해결해주지는 않음
    기획단계, 개발단꼐에서 인지하지 못한 버그는 나올 수 있다
    버그를 완전히 없애는 것이 아니라 미ㅣㄹ 인지한 버스를 최대한 빨리 발견해서 고객이 사용하기 전에 버그를 먼저 발견해서 선제 대응할 수 있는 장치를 마련하는 것이 목적

    TDD vs XP(익스트림 프로그래밍)
    왈 "불안함을 지루함으로 만들어주는 마법의 돌"
    하지만 내가 인지하지 못한 버그를 테스트가 발견했을 때,
    담당하고 있는 코드에만 집중하게 되는데 작

    okkycon - 이규원 등 강의 찾아서 살 붙이기
    1.TDD란?
    2.TDD방법론에 대한 찬반(반대 개념) + 장단점
    3.타입
    4.규칙
    5.실제 코드

    짧은 주기로 피드백을 받아가며 프로그래머가 코드를 늘려가는 개발 방법론

vue + tdd (jest, vue components -> jest module)

red : 기대되는 행동에 대한 테스트를 작성
green : 테스트 패스 위해 코드 작성
refactor : 리팩토링

이전 테스트 통과도 확인하니까 빠르게 디버깅 가능
클린코드 가능

jest

  • import, export, 상태 관리, configuration에서 에러가 많이 남

    vitest

  • modern js

  • typescript, import, export support, configuration 필요 없음

  • v-bundler 사용하면 바로 사용 가능

  • 어떤 프로젝트에서든 사용할 수 있다

자바스크립트 테스트 프레임워크

Jest

  • 메타에서 만든 테스팅 라이브러리

  • 마찬가지로 메타에서 만든 react에서 많이 사용

  • Jasmine에 기반을 두고

  • 커뮤니티와 support 빵빵

    장점

  • 퍼포먼스 : 사이즈가 큰 프로젝트를 CI/CD할 때 편함

  • 다른 애플리케이션과 통합하기 좋다,

  • auto mocking

  • extended API

  • timer mocks

  • active development & comm

    Mocha

    Jasmine

    좋은 테스트를 작성하는 방법
    테스트를 작성해야 하는 이유

  • 잘못 작성했을 때를 대비해서 에러 확인하기 좋으니까

  • 유닛테스트 : 코드의 가장 작은 단위를 테스트하는 것 ex. 함수
    여러개를 확인하기 어렵고 에러를 특정 짓기 어렵기 때문에!
    불안감을 지루함으로 교환해준다

TDD란?

출처

  • Test Driven Development
  • 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나
  • 개발에 있어서 테스트가 주가 되어 개발한다 ("테스트를 염두에 둔 프로그램 개발 방법")
  • 이 기법을 '재발견'한 것으로 인정되는 Kent beck에 의하면('Test Driven Development:By Example') : 테스트 작성 - 통과하는 코드 작성 - 래팩토링
  • 즉 테스트가 없던 레거시 코드의 버그를 고치거나 리팩토링하기 전에 테스트를 추가하는 것은 맞다고 하더라도 뒤늦게 테스트를 추가하는 작업은 엄밀히 TDD에 해당하지는 않는다
  1. 개발자는 초기적 결함을 점검하는 자동화된 테스트케이스 A를 작성한다
  2. 테스트케이스 A를 통과하기 위한 최소한의 코드를 작성한다
  3. 2번의 새 코드를 표준에 맞도록 리팩토링한다

TDD의 장점

  1. 객체 지향적인 코드 개발
  • 좀 더 명확한 기능과 구조 설계 가능
    : 각각의 함수를 정의할 때 각각의 기능들에 대해 철저히 구조화시켜 코드를 작성할 수 있다
    : 테스트의 용이성(속도, 재사용성)을 위해 복잡한 기능을 가진 함수 작성 지양
  1. 설계 수정 시간 단축
  • 테스트 코드 먼저 작성
    1) 최초 설계안을 만족시키며 입출력 구조와 기능의 정의를 명확히 하게 된다
    -> 설계의 구조적 문제를 바로 찾아낼 수 있다 ex. 인터페이스나 클래스의 구조들 많이 수정
    2) 미리 테스트 시나리오를 작성해봄
    -> 코드 개발 전 기능을 구현하기 위한 예외 상황들을 미리 확인해보고 조사하게 되는 효과가 발생, 예외 코드를 작성하기 쉬워진다
  1. 디버깅 시간의 단축
  • 단위 테스트 기반의 테스트 코드를 작성
    : 추후 문제가 발생했을 때 각각의 모듈 별로 테스트를 진행해보면 문제의 지점을 쉽게 찾아낼 수 있다
    : TDD가 아니면 모든 영역의 코드를 봐야한다 (DB, applictation, data, memory 등의 영역)
  1. 유지 보수의 용이성
  • 설계 및 작성 시 기술적인 관점으로 보게 된다
    : 기능 자체의 실현에 목적을 두기 때문에 코드가 복잡해지고 테스트가 어려워진다
    : TDD를 쓰면 테스트 요소들이 사용자 관점으로 정의되고 진행되기 때문에
    (1) 입력과 출력의 흐름이 명확해지고
    (2) 후추 구조의 변경 및 소스 수정 시 구조를 쉽게 파악하고 빠른 수정이 가능해진다
    (3) 재사용 테스트도 쉽게 가능해진다
  1. 테스트 문서의 대체 가능
  • TDD가 아니라면 단순 통합 테스트 : 내부적으로 개별적인 모듈들이 어떻게 테스트 되었는지 제공할 수 없다
  • TDD를 구현하게 될 경우:
    1) 테스팅을 자동화시킴과 동시에
    2) 보다 정확한 테스트 근거를 산출할 수 있다
profile
해피데빙
노션 : https://garrulous-gander-3f2.notion.site/c488d337791c4c4cb6d93cb9fcc26f17
이전 포스트

err_address_unreachable

다음 포스트

실시간 : socket + redis pub/sub

0개의 댓글