basic of tdd with swift

TDD

What is the TDD?

Test-Driven Developement

테스트 주도 개발

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle:

first an (initially failing) automated test case is written that defines a desired improvement or new function.

Then, the minimum amount of code is written to pass that test,

and finally one refactors the new code to acceptable standards.

Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

WIKI

위키테스트 주도 개발 (Test-driven development TDD) 은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다 .

우선 개발자는 바라는 향상 또는 새로운 함수를 정의하는 ( 초기적 결함을 점검하는 ) 자동화된 테스트 케이스를 작성한다 .

그런 후에 , 그 케이스를 통과하기 위한 최소한의 양의 코드를 생성한다 . 그리고 마지막으로 그 새 코드를 표준에 맞도록 리팩토링한다 .

이 기법을 개발했거나 ' 재발견 ' 한 것으로 인정되는 Kent Beck 은 2003 년에 TDD 가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다 .

밥아저씨의 TDD 규칙

TDD 법칙 3 가지• 첫째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다 .• 둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다 .• 셋째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다 .

1 단계테스트 케이스 작성

2 단계테스크 코드를 통과하는 코드 작성

3 단계리팩토링

깨끗한 테스트 코드• 테스트 코드는 실제 코드 못지 않게 중요하다 .• 테스트는 유연성 , 유지 보수성 , 재사용성을 제공한다 .

깨끗한 테스트 코드• 깨끗한 테스트 코드를 만들기 위해서는 3 가지가 필요하다 .

• 가독성 , 가독성 , 가독성

테스트당 개념 하나• given-when-then• precondition-invocation-assertion

테스트 함수당 Assertion 하나

• One Assertion Per One Test Function

F.I.R.S.T• Fast- 빠르게• Independent- 독립적으로• Repeatable- 반복가능하게• Self-Validating- 자가검증하는• Timely- 적시에

RED

GREENREFACTOR

TDD

Write failing test

Make it passImprove the code

Advantages of TDD• You only write code that is needed• More modular design• Easier to maintain• Easier to refactor• High test coverage: confidence in your code• Tests document the code• Less debugging

Disadvantages of TDD

• No silver bullet: help to find bugs vs can’t find bugs

• It seems slower at the beginning• All the members of a team need to do it• Tests need to be maintained when

requirements change

Questions when writing the test

• Precondition: What is the state of the system before we invoke the method?

• Invocation: How should the signature of the method look? What are the input parameters (if any) of the methods?

• Assertion: What is the expected result of the method inovation?