Embedded C에서 TDD를 실천하기 위해 시도했던 경험과 방법을 기록해 보았습니다.
HW로부터 생기는 버그인지 SW로부터 생기는 버그인지 짐작조차 되지 않는 상황이 자주 발생한다면, TDD를 시작해보세요.
이 자료에서는 호스트 시스템(PC)에서 TDD를 실천하는 방법과 타깃 시스템(nRF51-DK)에서 TDD를 실천하는 방법을 기록하였습니다.
또한, nRF51-DK가 아닌 다른 보드를 가지고 있더라도 실천 가능합니다.
ktim610@gmail.com
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기Ahreum Kim
2018. 11. 03 'FEConf 2018' 발표자료입니다.
---
처음으로 프론트엔드 프로젝트에 (유닛)테스트코드를 작성해보며 느낀 경험을 공유합니다. 어떤 관점으로 접근 했는지부터, 테스트코드 작성을 하며 만난 고민과 해결책은 어떤 방식으로 풀어 냈는지 코드와 함께 다뤄보려 합니다. 저는 테스트 숙련자가 아니지만, 저와 비슷한 위치에서 테스트에 입문하시려는 분들께 어떻게 테스트에 입문하고 코드를 작성했는지에 대해서 구체적인 경험을 공유하는 것도 의미있을 거라 생각했습니다. 제가 드릴 얘기들이 정답이 아닐 수 있지만, 더 좋은 방향을 고민하면서 같이 생각해볼 수 있다면 좋겠습니다.
Embedded C에서 TDD를 실천하기 위해 시도했던 경험과 방법을 기록해 보았습니다.
HW로부터 생기는 버그인지 SW로부터 생기는 버그인지 짐작조차 되지 않는 상황이 자주 발생한다면, TDD를 시작해보세요.
이 자료에서는 호스트 시스템(PC)에서 TDD를 실천하는 방법과 타깃 시스템(nRF51-DK)에서 TDD를 실천하는 방법을 기록하였습니다.
또한, nRF51-DK가 아닌 다른 보드를 가지고 있더라도 실천 가능합니다.
ktim610@gmail.com
[FEConf 2018] Front-End 프로젝트의 Test code 작성경험기Ahreum Kim
2018. 11. 03 'FEConf 2018' 발표자료입니다.
---
처음으로 프론트엔드 프로젝트에 (유닛)테스트코드를 작성해보며 느낀 경험을 공유합니다. 어떤 관점으로 접근 했는지부터, 테스트코드 작성을 하며 만난 고민과 해결책은 어떤 방식으로 풀어 냈는지 코드와 함께 다뤄보려 합니다. 저는 테스트 숙련자가 아니지만, 저와 비슷한 위치에서 테스트에 입문하시려는 분들께 어떻게 테스트에 입문하고 코드를 작성했는지에 대해서 구체적인 경험을 공유하는 것도 의미있을 거라 생각했습니다. 제가 드릴 얘기들이 정답이 아닐 수 있지만, 더 좋은 방향을 고민하면서 같이 생각해볼 수 있다면 좋겠습니다.
iOS 에서 TDD 도전해보기.
2022년 11월 24일 새싹 세미나에서 공유.
-> 아래 피그마 링크에서 더 보기 편하게 보실 수 있습니다.
https://bit.ly/3ExvmaI
----------------------------
01. TDD 테스트 주도개발
1) TDD의 정의
2) 사용해야하는 이유
3) 장단점
4) TDD 방법
02. XCTest: iOS에서의 TDD
1) XCTest란
2) 작성할 수 있는 테스트
3) setUp, tearDown
03. UNIT TEST 실습: XCTest로 테스트하기
1) XCTest 세팅
2) 테스트 작성 방법
3) 테스트할 기능 미리보기
4) 단위테스트 해보기
04. epliogue: 덧붙이는 말
1) TDD 잘하는 방법
2) 참고문헌 및 링크
3) 감사의 말
2. TDD와 BDD는 어떻게 다른가?
• TDD가 먼저 나왔다.
• BDD는 TDD의 개념을 승계해서 탄생했다.
3. TDD는 왜 탄생했나?
• 테스트 코드 없이 그냥 개발하던 시절이 있었다.
• Kent Beck이라는 사람이 테스트로 검증된 코드로 실제 코드를 작성하자고 업계
에서 주장
• 이 사람 주도 하에 TDD가 발전
4. 개발 전에 테스트 코드를
먼저 쓰자는 TDD??
• 꼭 그렇진 않다.
• 문제를 정의하고 해답을 찾아가는 과정이라는 게 TDD의 기본 취지
• 개발자가 뭘 개발 해야되는지를 확실히 알고 개발하자는 게 TDD의 취지
• 테스트 코드는 그 철학을 이행하는 도구일 뿐
5. TDD는 테스트 코드를 어떻게?
• 유닛을 위한 테스트 셋을 정의
• 개발 코드로 유닛을 구현
• 마지막으로 유닛에 대한 구현이 테스트를 통과 하는지 검증
6. TDD의 기본 인터페이스
• 유닛을 위한 테스트 셋을 정의
• 개발 코드로 유닛을 구현
• 유닛에 대한 구현이 테스트를 통과 하는지 검
증
7. 테스트 코드를 먼저 짜고,
그 다음에 개발 코드를 짜는 건 맞지 않는가?
• 맞음
• Red - Green - Refactor 방식으로 진행
• 하지만 테스트 코드로 개발을 먼저 시작하자는 게 TDD의 기본 철학은 아님
8. 근데 왜 BDD가 나오게 되었나?
• TDD 개념으로 다른 개발자들에게 코치를 하던 Dan north라는 사람
• 어느날 TDD에서의 빈틈을 느끼기 시작
• 프로세스의 어디서 부터 시작해야 하는가
• 무엇을 테스트하고 또 무엇을 하지 말아야 하는가
• 한번에 얼마만큼 테스트해야 하는가
• 테스트를 어떻게 명명해야 하는가
• 테스트가 실패 하는 지에 대해 어떻게 이해해야 하는가
9. TDD의 한계를 느꼈다는 말인 것 같은데,
그럼 그 빈틈을 어떻게 해결하고자 했는가?
• 특정 값이 주어지고 (Given)
• 어떤 이벤트가 발생했을 때 (When)
• 그에 대한 결과를 보장해야한다 (Then)
• 위의 형식을 만들어서 테스트 코드를 짜기 시작
10. 그 형식을 쓰는 것만으로도
BDD라고 볼 수 있는 건가?
• Dan north는 애초에 Test라는 단어를 쓰지 않는 게 TDD의 원리를 더 파악하기
쉽다고 생각
• Test라는 단어보다는 Behavior 이라는 표현을 쓰는 게 더 낫다고 판단
11. 기존의 TDD 인터페이스에는 suit - test
형식이 있었는데 그럼 바뀐다는 말인가?
• test라는 단어를 없앰
• describe - it - should라는 패턴으로 변경
12. test라는 단어만 없고 결국 TDD
인터페이스랑 비슷한 것 같은데?
• 맞다. 둘다 별 차이가 없다.
• BDD는 기술 언어가 아닌 자연어에 가깝게 테스트 스펙을 기술한다는 것이 포인
트
• TDD와 BDD 중 뭐가 낫고 별로냐는 논쟁은 소모적인 논쟁
13. 결국 TDD와 BDD는 테스트 코
드 인터페이스만 다를 거 아닌가?
• 맞다.
• 둘 다 Red - Green - Refactor 흐름으로 진행
• given - when - then 패턴으로 테스트 코드가 작성된다고 보면 됨