TDD (test driven development)

What is testing

Software testing

Quality, bug

함수, 기능, ui, 성능, api스펙 을 test 하여 작동여부를 확인 후 패스하거나 다시 만드는 것을 말합니다.

** 일부회사에서는 검증팀이 따로 있어 코드를 검토했지만, 비효율적인 문제로 자동화 된 추세로 변화되었다. 하지만 이 문제도 개선은 되어도 비효율적인 문제가 있어 개발과 동시에 테스트를 할 수 있도록 시스템이 변모되었다.
위 개선점에도 불구하고 규모가 있는회사는 qa팀을 별도로 운영하고 있다.

Why software test(reason)

기능 정상 작동
요구사항 적용
이슈 예측
빠른 버그 수정
리팩토링의 효율성 상승
모듈간 독립적인 코드사용(재사용가능)
코드품질 향상
문서화 가능
시간절약가능

Test pyramid(필수테스트)

Unit (함수, 모듈, 클래스)
** 회사마다 쪼개는 단위는 다를 수 있음.
Integration(위의 요소의 상호작용)
End to end (ui, 사용자입장의 테스트)

why named pyramid
비용, 시간, 측면(위로 올라갈수록 비용이 올라감)

Why TDD

TDD는 사전에 기능단위를 최소한으로 작성하는 것을 말하는데
기능단위로 분리해 작성을 하는데 있어 필요한 것들 예를들어
사용자의 입장에 있어서 필요한 사항들, 목표점검, 시스템 전반 에 대하여 정리 점검 후 코드를 작성하기 떄문에 더더욱 각광 받고 있다.
개발자 개인 역량에 따라 하는사람과 않하는 사람이 고 사내 문화적으로도 다르지만 습관적으로 테스트를 하고 협업하는 사람이 아무래도 좋은평가를 받기 좋고, 협업시 불필요한 불협화음 피할 수 있다.

Process

테스트 통과용의 최소한의 코드를 작성 -> 검수 -> 재작성 -> 검수 후 통과
통과된 코드를 리팩토링 -> 검수 -> 재작성 -> 검수 통과되면 완성

CI/CD

(Code build test release deploy)
the time when I merge deposit에 변경사항을
주기적으로(테스트코드 포함)확인하고 통합을 하기위한 단계
(통합시 정상적으로 작동이 되는지, 지금까지 테스트가 이상없는지 )

위 두가지를 계속 확인하면서 지속적인 배포를 위해 TDD는 중요하다!

Assertion - 조건 비교를 통한 테스트 로직
Test runner - 테스트 실행후 결과 생성

TEST 종류

Unit
Functional
Component
Unit
Contract
Integration