중뱃살(주도로)

1. TDD
Class101@Joy

2. 불확실성
1. 정확성
•무엇이 일어날 지 확정적으로 알고 있는 경우
2. 리스크
•무엇이 일어날 진 모르지만, 일어날 수 있는 경우에 대해 아는 경우
•그 정도를 확률적으로 나타낼 수 있는 경우
3. 불확실성
•무엇이 일어날 진 모르지만, 일어날 수 있는 경우에 대해 아는 경우
•하지만 확률적으로 잘 모르는 경우
4. 무지 (멍청함)
•전혀 예측할 수 없고, 일어날 지도 모르는 경우

3. 소프트웨어 불확실성
1. 개발자가 어떤 부분에 대해 코딩을 여러번 해보아 결과가 자명한 경우
2. 개발 스펙, 고객의 요구조건이 변하지 않는 경우
3. 개발하고 나서 유지보수를 내가 하는 경우
4. 주변 환경이 변하지 않는 경우 (시간, 자원, 외부 라이브러리 등)
“확실한” 소프트웨어는 존재하는거야?

4. 소프트웨어 불확실성
원래 모든 일은 불확실하며,
고객은 무지하고,
주어진 자원은 유한합니다…

5. 불확실성을 낮추려면?
보통 미래에 일어날 일에 대한 불확실성이라는 것은,
1. 시간이 지나면 자연스럽게 줄어듭니다
2. 아는 지식이 많아진다면 줄어들게 됩니다

6. 불확실성을 낮추려면?
예를 들어 오늘 조이가 먹을 저녁 메뉴가 무엇인지 알고 싶다고 가정하자.
그렇다면 저녁시간이 가까워 질수록 불확실성이 줄어들고,
오늘 조이가 먹은 점심이 무엇인지에 따라서 불확실성이 줄어듭니다.
불확실한 것
시간의 경과
지식

7. 협력과 피드백
하지만 우리는 시간이 지나가길 기다릴 수 없습니다. ㅠㅜ
우리는 더 빠르게 지식을 습득하여야 합니다.
그렇게 하기 위해서 우리는
협력과 피드백(애자일의 핵심)을 자주 해야 합니다.

8. 협력과 피드백
우리 개발팀이 하고 있는 협력은…
코드 리뷰 매주 회의

9. 협력과 피드백
우리 개발팀이 받을 수 있는 피드백은…
앱스토어 리뷰
여러 종류의 Error Alert
CS

10. 협력과 피드백
Problem!
협력, 피드백의 주기가 너무 길다!
지식의 공유가 잘 일어나기 위해선 개발팀이 더 자주 협력하여야 하고,
제품의 품질을 높이기 위해선 피드백을 더 자주 받아 더 자주 개선하여야 한다.

11. TDD
Test Driven Development
테스트 주도 개발
테스트가 개발을 이끌어 나간다

12. TDD
보통은 개발자가 개발이 끝나고 나면 테스트를 한다.
이것의 순서를 바꾸는 것을 TDD라고 이해하자.
테스트를 먼저 만들고 테스트를 통과하는 코드를 짜는 것.
우선 테스트를 작성하고 그걸 통과하는 코드를 만들고 이를 반복하면서
제대로 동작하는지에 대한 피드백을 적극적으로 받는 것이다.

13. TDD
TDD 하면, 피드백을 더 자주 받을 수 있다.
코드를 배포하고 고객이 써보고 난 뒤에 얻는 피드백보다
내 터미널에서 바로 피드백을 얻을 수 있다

14. TDD
TDD 하면, 협력이 용이해진다.
테스트라는 것은 어떤 행동을 코드로 정의한 것이기 때문에,
행동을 전달할 수 있고, 공유하기 쉬워진다.

15. TDD
✓ 비율 정산 값이 올바른 경우, KlassStore의 정산 비율을 수정할 수 있다
✓ 비율 정산 값이 올바르지 않은 경우, 오류가 발생한다
TDD 하면, 협력이 용이해진다.
테스트라는 것은 어떤 행동을 코드로 정의한 것이기 때문에,
행동을 전달할 수 있고, 공유하기 쉬워진다.

16. TDD
내가 짠 코드를 남에게 공유하고 이해시키기 쉽고
남이 짠 코드를 내가 이해하기 쉽고,
내가 그 사람의 의도를 모르고 코드를 고칠 일이 없고,
용기가 생기며,
테스트 코드에는 구현부 코드에선 알 수 없는 의도와 결정이 보이며,
코드 리뷰를 하더라도, 테스트 케이스만이라도 확인할 수 있고,
남이 짠 코드를 망치더라도 쉽게 알아챌 수 있고,
이 모든 것들은 협력할 때 비용을 매우 획기적으로 줄여줍니다.

17. TDD
빠른 피드백과, 적은 협력 비용으로
우리 개발팀이 지식을 쉽게 습득하고 공유하여
불확실성에 대비하는 것이
TDD의 핵심

18. TDD
But,
개인이 느끼는 개발 시간이 최대 150%까지 늘어날 수 있음
하지만 프로젝트 전체로 보면 결함이 줄어들고,
협력 비용이 줄어 이득이라 볼 수 있음
TDD를 한다고 해서 좋은 코드와 설계가 나오는 것은 아님.
(리펙터링 과정에서 고민하지 않는다면…)

19. TDD
Given When Then/AAA를 따른다면 케이스를 작성하기 쉬워집니다.

20. TDD
it(“어떤 값이 주어졌고, 어떤 조건일 때 어떠하게 동작한다”) {
/// 테스트 케이스의 내용은
// Arrange
// Act
// Assert
}
형태로 작성합니다.

21. TDD
1. 무엇을 테스트할지 정하기 어렵다면?
외부 서비스나 라이브러리를 쓰지 않는 코드부터 작성한다.
입력과 출력이 동기에 일어나는 명확한 함수부터 작성한다.
Private 함수는 작성하지 않는다.
꼭 테스트 코드부터 짤 필요는 없다.
아주 조금의 대역을 만들어 두는 것이 도움을 줄 때가 있다.

22. TDD
2. 테스트를 통과했는데 리펙터링은 어떻게 해야하나?
테스트를 통과하기 위해 작성한 코드다보니
굳이 노출되지 않아도 되는 부분을 노출하거나,
바운더리를 넘어가는 경우가 발생하기 마련인데,
이런 부분을 중점적으로 개선합니다.
필요하다면 리펙터링 도중에 케이스를 추가하여도 됩니다.

23. TDD
3. 기존에 있던 로직에 기능을 추가하면서 테스트를 해야하는데 이 경우엔?
신규 기능이 들어갈 앞/뒤 로직의 의존성을
일단 간단하게 만들고, 추상 클래스/인터페이스나 함수로 만들어버립니다.
그리고 나서 해당 로직 앞부분을 Mocking하고 테스트를 작성합니다.
그리고 원하는 기능을 추가하고,
리팩터링 할 때 만들어진
추상 클래스, 인터페이스에 대한 테스트를 작성합니다.

24. 핑-퐁 프로그래밍
1. 한사람은 테스트 케이스를 작성한다
2. 작성이 끝나면 다른 사람이 구현부분을 작성한다.
3. 다시 다른 한 사람이 리펙터링을 진행한다.
4. 위 과정을 반복한다

25. DEMO

26. 참조
도서, 소프트웨어 장인
https://blog.outsider.ne.kr/669
https://ko.wikipedia.org/wiki/불확실성
https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html
https://knowyourmeme.com/memes/tree-swing-cartoon-parodies