#testing
노트 31개
Frontend
Accessibility장애가 있는 사람도 웹을 인지하고 조작하고 이해할 수 있게 만드는 일. 장애는 능력과 환경의 불일치이고, 브라우저는 시맨틱 HTML로 접근성 트리를 만들어 보조 기술에 넘기며, WCAG가 최소선을 정한다. 표준을 지켜도 쓰기 어려울 수 있어 장애인과의 사용성 테스트와 조직 차원의 우선순위가 필요하다. 사용자 관점과 WCAG, 시맨틱 구조·대체 텍스트·폼·ARIA·키보드·위젯·CSS 기법, 자동·수동 평가와 스크린 리더 테스트를 하위 노트로 잇는다.
Frontend › Accessibility
스크린 리더로 테스트하기스크린 리더 테스트는 읽는 순서, 대체 텍스트, 제목·랜드마크·폼·표의 의미가 실제로 어떻게 들리는지 확인한다. 데스크톱은 NVDA나 JAWS 하나에 VoiceOver를, 모바일은 iOS VoiceOver와 Android TalkBack을 쓰고, 각 스크린 리더의 최소 단축키(읽기 시작·중지, 제목·랜드마크·폼 이동, 요소 목록)만 익히면 기본 점검이 된다.
Frontend › Accessibility
접근성 평가 방법과 도구접근성 감사는 기준선을 잡고 개발 주기 내내 반복하는 자동·수동·보조 기술 테스트의 조합이다. 자동 검사 도구는 명백한 오류와 사람이 볼 곳을 짚어 줄 뿐 접근 가능한지는 판정하지 못하므로, DevTools로 이름을 확인하고 키보드·시각·콘텐츠·확대·스크린 리더 순으로 수동 점검한다. 결과는 ACR(VPAT)로 보고하고, 오버레이 제품은 이 과정을 대신하지 못한다.
Frontend › Accessibility
WCAG와 POUR 원칙WCAG는 인지·운용·이해·견고(POUR) 네 원칙 아래 13개 지침과 성공 기준으로 웹 콘텐츠 접근성의 최소선을 정한다. 2026년 기준 권고안은 WCAG 2.2(86개 기준, 4.1.1 삭제)이고 따로 요구되는 기준이 없으면 AA를 목표로 한다. 형제 지침(ATAG·UAAG)과 각국 법, 원칙별 점검 질문, 모든 성공 기준의 체크리스트를 정리했다.
Frontend › Mobile
모바일 앱 출시 과정모바일 앱은 스토어 심사를 거쳐야 사용자에게 닿기 때문에 웹 배포와 절차가 다르다. 개발자 등록, 빌드와 테스트, 내부·외부 베타와 회귀 테스트, 내부 승인과 정책 준수, 스토어 최적화(ASO), App Store Connect·Google Play Console 제출, 단계적 출시까지의 흐름을 정리한다.
Frontend
Testing프론트엔드 코드의 동작을 테스트로 보장하고, 테스트로 설계를 이끄는 방법.
Frontend › Testing
의존성이 있는 컴포넌트 테스트하기fetch로 데이터를 받고, 자식 컴포넌트를 가져오고, Context에서 콜백을 받는 컴포넌트를 Vitest와 Testing Library로 테스트하는 세 가지 기법: 전역 fetch 바꿔 끼우기(vi.stubGlobal), 모듈 목(vi.mock), Provider로 테스트용 값 주입. 각 기법의 정리 방법과 한계, 그리고 MSW와 테스트하기 쉬운 설계로 넘어갈 시점을 정리한다.
Frontend › Testing
접근성 기반 UI 테스트 자동화UI 테스트가 xpath·CSS 선택자 때문에 쉽게 깨지던 문제를 WAI-ARIA의 role과 접근 가능한 이름(accessible name)으로 요소를 찾는 방식으로 푸는 법. getByRole 쿼리, aria-label·aria-labelledby·aria-current·aria-expanded 활용, 헤드리스 컴포넌트, 인수·회귀 테스트로서의 효과, 접근성 트리를 LLM·AI 에이전트의 입력으로 쓰는 법을 정리한다.
Frontend › Testing
정적 분석: 실행하지 않고 검사하기코드를 실행하지도, 테스트를 쓰지도 않고 자동으로 검사하는 정적 분석을 테스트의 맨 아래 층으로 본다. ESLint 규칙(no-unsafe-finally 같은 올바르지만 틀린 코드, eslint-plugin-compat 같은 브라우저 지원 검사)과 TypeScript 타입 검사(noImplicitAny, 검사 대상 포함 확인)가 무엇을 잡고, 무엇은 여전히 테스트로 확인해야 하는지 정리한다.
Frontend › Testing
테스트 실행 환경: Node, DOM 에뮬레이션, 실제 브라우저테스트가 도는 런타임(Node·Deno·Bun 또는 브라우저)과 그 안에서 쓸 수 있는 API가 테스트 환경이다. 순수 로직은 어디서든, 작은 컴포넌트는 jsdom·happy-dom 같은 DOM 에뮬레이션에서, 레이아웃·제스처·사용자 흐름은 실제 브라우저(CI에서는 헤드리스, 필요하면 Xvfb)에서 테스트한다. 환경에 기대지 않는 로직을 떼어 낼수록 테스트가 쉬워진다.
Frontend › Testing
테스트를 돌리는 시점: 로컬, PR, CI테스트는 개발 중 watch 모드로, 병합 전 PR 상태 검사로, 병합 뒤 main 브랜치의 CI로 세 번 돈다. 기본 test 스크립트는 몇 초 안에 끝나게 두고, PR에서 통과했는데 CI에서 깨지는 이유(변경 간 경합, 플레이키 테스트, 매번 돌리지 않는 비싼 테스트)와 빨간 빌드에 되돌리기·앞으로 고치기로 대응하는 법, 경보 피로를 줄이는 법, 한 파일 커버리지·테스트 파일 제외·타임존 고정 같은 실행 옵션을 정리한다.
Frontend › Testing
테스트의 기본 요소: 테스트 케이스, 단언, 스위트, 수명 주기 훅거의 모든 테스트 프레임워크가 주는 공통 부품을 정리한다. 실패하면 던지는 단언(참·동등·깊은 동등), assert 스타일과 expect(BDD) 스타일, 스냅숏 단언, 테스트 케이스와 스위트(test·suite / it·describe), beforeEach·afterEach·beforeAll·afterAll, 비동기 코드를 기다리는 법(async·resolves/rejects·expect.assertions)과 가짜 타이머, 테스트 파일을 두는 위치. 이름은 도구마다 달라도 개념은 같다.
Frontend › Testing
프론트엔드 테스트의 종류와 도구정적·단위·통합·E2E 테스트가 각각 무엇을 확인하는지, 무엇부터 테스트할지, 피라미드·트로피 같은 전략의 모양과 스모크·회귀·시각 같은 목적별 테스트, 폴더 역할(apis·components·hooks·context·pages)별로 무엇을 검증할지, 테스트 대역(더미·스텁·스파이·페이크·목)의 차이, 구현이 아니라 사용자 행위를 검증하는 원칙과 테스트 작성 원칙(AAA, 블랙박스, 현실적인 데이터), 그리고 층마다 쓰는 도구(TypeScript·ESLint, Vitest·Jest, Testing Library, MSW, Playwright).
Frontend › Testing
프론트엔드에서의 TDD실패하는 테스트를 먼저 쓰고 통과시킨 뒤 리팩터링하는 TDD를 프론트엔드에 적용하는 방법. 목표와 사이클, 이점과 오해, BDD와의 차이(Given-When-Then, 이중 루프), 테스트하기 좋은 코드, Testing Library 예제, 현실적인 도입 순서.
Frontend › Testing
험블 객체 패턴: 테스트하기 쉬운 코드가 좋은 코드인 이유목은 비용에 따라 네트워크 목·전역 목·스파이·더미/스텁 네 단계로 나뉘고, 비싼 목이 많다는 것은 설계 문제의 신호다. 전역 객체·네트워크처럼 테스트하기 어려운 코드를 얇은 험블 객체로 떼어 내 인터페이스 뒤에 두면 나머지는 더미와 스텁만으로 테스트되고, 코드는 자연스럽게 SOLID에 가까워진다.
Frontend › Testing
API 모킹: MSW와 json-server백엔드 API가 없거나 불안정할 때 프론트엔드가 가짜 응답으로 개발·테스트하는 방법. 코드 속 가짜 데이터, json-server 같은 가짜 REST 서버, 네트워크 단에서 요청을 가로채는 MSW를 비교하고, MSW 2의 핸들러(http·HttpResponse)와 브라우저(Service Worker)·Node(setupServer) 설정, 테스트에서 핸들러를 바꿔 끼우는 법을 정리한다.
Frontend › Testing
JavaScript 테스트 모범 사례'테스트는 보자마자 이해되게 단순하게'라는 황금률에서 나오는 원칙들을 한곳에 모았다. 테스트 이름·AAA·블랙박스·테스트 대역 고르기, 현실적인 데이터와 필요한 것만 드러내기, 프런트엔드와 E2E, 백엔드 컴포넌트 테스트와 HTTP 가로채기·장애 시나리오·검증할 결과 다섯 가지·DB 정리 전략, 커버리지와 뮤테이션 테스트, CI에서 지킬 것까지.
Frontend › Testing
Storybook: 컴포넌트를 상태별로 떼어 보는 도구컴포넌트를 앱에서 떼어 내 상태별 '스토리'로 등록하고 보고·조작·테스트하는 UI 작업장. CSF3 스토리 객체와 args·argTypes, meta·스토리·전역 3단계 설정, decorators, 사이드바 계층, Storybook 9부터 코어에 들어간 Controls·Actions·Viewport 같은 도구, TypeScript의 Meta·StoryObj와 satisfies, 스토리를 그대로 테스트로 쓰는 흐름까지 정리한다.
Backend › Web Basics
API 테스트의 종류API를 검증하는 아홉 가지 테스트(스모크, 기능, 통합, 회귀, 부하, 스트레스, 보안, UI, 퍼즈)가 각각 어떤 질문에 답하는지, 개발에서 배포까지 어느 단계에서 돌리는지, 부하와 스트레스의 차이와 퍼즈 테스트가 찾는 것을 정리했다.
Backend
백엔드 테스트: 범위, 대역, 구조, 자동화도메인 로직은 프레임워크 없는 단위 테스트로, 경계는 실제 자원이나 에뮬레이터(Testcontainers·LocalStack)로 검증한다. 목은 통제할 수 없는 의존성에만 쓰고, 테스트는 공개 인터페이스만 보며 수를 줄인다. Describe-Context-It으로 구조화하고, CI는 결과를 PR 단계에 보여 준다.
Computer Science
정보처리기사정보처리기사 실기에서 여러 회차에 반복해서 나오는 개념을 주제별로 묶은 요약 노트 모음.
Computer Science › Engineer Information Processing
소프트웨어 테스트ISO/IEC 25010 품질 특성과 McCall 모델, 품질 보증·품질 관리·감사와 테스트의 차이, 테스트 원리와 에러·결함·고장, V-모델의 테스트 레벨과 검증·확인, 명세 기반 기법(동등 분할·경곗값·결정 테이블·상태 전이·페어와이즈)과 구조 기반 커버리지(문장~MC/DC)의 실제 케이스 도출, 테스트 오라클, 통합 테스트, ISO/IEC/IEEE 29119 테스트 프로세스와 위험 기반 테스트, 결함 관리, AI 소프트웨어 테스트(변성 테스팅, 뉴런 커버리지) 정리.
Computer Science › Programming Languages
좋은 코드를 위한 열 가지 원칙코드 규약 준수, 이유를 남기는 주석, 견고함, SOLID, 테스트하기 쉬운 구조, 적당한 추상화, 과설계 없는 패턴 사용, 전역 의존 줄이기, 지속적인 리팩터링, 보안 우선이라는 열 가지 코딩 원칙을 각각 왜 필요한지와 함께 정리하고, 원칙끼리 부딪칠 때의 판단 기준을 덧붙인다.
Computer Science
소프트웨어 안전: 위험원 분석과 결함 허용 설계허용 가능한 위험만 남은 상태를 안전으로 정의하고, 소프트웨어 결함이 사고로 이어진 사례, 결함 예방·검출·제거·허용의 네 전략, 중복성과 다양성, IEC 61508을 뿌리로 한 분야별 안전 표준과 SIL, FMEA·FTA·HAZOP 안전 분석을 정리한다.
DevOps
DevOps, SRE, 플랫폼 엔지니어링, NoOps와 클라우드 거버넌스개발과 운영을 잇는 방식의 갈래를 비교한다. DevOps는 협업 문화와 자동화, SRE는 SLO·에러 버짓으로 신뢰성을 공학 문제로 다루는 실천, 플랫폼 엔지니어링은 개발자가 스스로 쓰는 내부 플랫폼을 제품으로 만드는 일, NoOps는 서버리스로 운영 작업을 클라우드에 넘기는 지향이다. 클라우드를 들인 조직의 운영 모델(중앙 집중·분산·공유 서비스·CCoE), 통제가 아니라 가드레일로서의 거버넌스와 문화 전환, 테스트가 개발자 몫으로 옮겨 간 흐름과 회사 규모별 배포·품질 도구의 변화도 함께 다룬다.
AI & Data
평가 주도 개발(EDD): AI 기능을 테스트하며 다듬기평가 주도 개발은 TDD를 AI의 불확실성에 맞게 바꾼 개발 방식이다. 문제를 API 계약처럼 정의하고, 제로샷 기준선을 만들고, 결정적 검사·사람·LLM 심판을 섞은 평가 체계를 세운 뒤, 작고 겨냥한 수정으로 프롬프트를 개선한다. 프롬프트·지표·테스트 입력은 코드처럼 버전 관리하고 CI에서 회귀를 막는다.
AI & Data
AI 모델로 완성도 높은 프론트엔드 디자인 뽑기AI는 상상보다 모방을 잘한다. 디자인 시스템·시각 레퍼런스(와이어프레임·스크린샷·무드보드)·서사·검증 도구를 미리 주고 기본 폰트·아이콘을 바꾸면 흔한 템플릿 대신 의도가 분명한 UI가 나온다.
AI & Data
AI 코딩 실무 가드레일AI 코딩 에이전트로 프로덕션 코드를 다룰 때의 실무 규칙. 프로젝트 규모에 따른 세 가지 모드, CLAUDE.md와 앵커 주석(AIDEV-NOTE), 테스트는 사람이 쓴다는 원칙, 맥락을 아끼지 않는 프롬프트, 작업마다 새 세션, AI가 건드리면 안 되는 영역과 실수의 등급을 정리한다.
Tools › Code Review
리팩터링 원칙마틴 파울러 『리팩터링』(2판) 1·2장에서 뽑은 원칙. 리팩터링의 정의, 기능 추가와 리팩터링을 나누는 두 개의 모자, 테스트 먼저, 3의 법칙, 성능은 다듬은 뒤에 챙긴다는 태도를 정리한다.
Career › Product
사용자 리서치: 방법 고르기, 페르소나·시나리오, 사용성 평가더블 다이아몬드의 단계마다 맞는 리서치 방법이 다르다. 사용자를 직접 못 만나면 리뷰·상담 기록·포럼을 쓰고, 조사 결과는 근거 있는 페르소나와 사용 전·중·후 UX 시나리오로 정리해 UX 전략으로 잇는다. 화면은 닐슨의 10가지 휴리스틱 평가와 5명 단위 사용성 테스트로 검증하고, 큰 조직에서는 정기 세션으로 학습 문화를 만든다. 급할수록 맥락·분석 시간·자기 디자인에 대한 애착을 경계하고, 참가자 보호를 위한 윤리 절차를 갖춘다.
Career › Product
BDD·SDD로 기획서를 태스크로 나누기기획·디자인·개발·QA가 같은 문서를 보도록 기획을 사용자 행동(BDD의 given-when-then)과 데이터 구조(SDD)로 정리해 태스크를 만드는 방법. then 하나가 태스크 하나가 되어 진척도·일정·테스트 범위가 함께 보이고, Figma에 디자인과 기획을 합쳐 두면 최신 화면까지 한곳에서 관리된다.