전통적인 개발과 테스트 주도 개발, 그리고 애자일
•
0 likes•262 views
전통적인 개발과 테스트 주도 개발은 어떻게 다를까? 전통적인 개발이 빠를까? 테스트 주도 개발이 빠를까? 테스트 주도 개발과 애자일은 어떤 관계가 있을까? 에 대한 발표 자료입니다. 발표문을 추가한 블로그 글 주소입니다. https://taptorestart.tistory.com/entry/%EC%A0%84%ED%86%B5%EC%A0%81%EC%9D%B8-%EA%B0%9C%EB%B0%9C%EA%B3%BC-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%95%A0%EC%9E%90%EC%9D%BC
Recommended
More Related Content
Similar to 전통적인 개발과 테스트 주도 개발, 그리고 애자일
Similar to 전통적인 개발과 테스트 주도 개발, 그리고 애자일 (20)
전통적인 개발과 테스트 주도 개발, 그리고 애자일
- 2. 전통적인 개발 기능 구현 개발자 직접 테스트
- 3. 🛠
- 4. 🛠
- 5. 🛠 🔥 🔥 🔥
- 6. 변경 비용 Cost of Change 시간 Time 출처: agilemodeling.com
- 8. 정신나간 것 같은 아이디어
- 9. “나와 함께 테스트 주도 코딩을 했던 모든 프로그래머들에게 감사한다. 특히 초기에 정말 정신나간 것 같은 아이디어를 감내하고 함께 일해준 인내력에 감사한다.” - 켄트 백. 「테스트 주도 개발」 감사의 글에서 출처: 켄트 벡, 「테스트 주도 개발」, 김창준, 강규영 역, (주)도서출판인사이트, p30
- 10. 테스트 주도 개발 Test-Driven Development
- 12. 작동하는 깔끔한 코드 Clean code that works 출처: 켄트 벡, 「테스트 주도 개발」, 김창준, 강규영 역, (주)도서출판인사이트, p21 론 제프리즈(Ron Jeffries)의 핵심을 찌르는 이 한마디가 바로 테스트 주도 개발의 궁극적인 목표다
- 13. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다. 중복을 제거한다. 테스트 주도 개발의 두 가지 규칙 출처: 켄트 벡, 「테스트 주도 개발」, 김창준, 강규영 역, (주)도서출판인사이트, p22
- 14. 🔴 실패하는 작은 테스트를 작성 🟢 빨리 테스트를 통과하게 만들기 🛠 리팩터링: 테스트를 통과하게 만드는 중에 생겨난 중복을 제거 출처: 켄트 벡, 「테스트 주도 개발」, 김창준, 강규영 역, (주)도서출판인사이트, p23
- 15. def test_sum() assert sum(1, 2) == 3
- 16. 테스트 주도 개발은 느리다?
- 17. 🟢 🟢 🛠
- 18. 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🛠 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢
- 19. 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🔴 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🛠 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🔴 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢 🟢
- 20. 변경 비용 Cost of Change 시간 Time 출처: agilemodeling.com
- 23. 사실 다른 사람에게 이런 식으로 개발하라고 설득하기는 녹록지 않다. 테스트를 작성하려면 소프트웨어 제품 본체 외의 부가적인 코드를 상당량 작성해야 한다. 그래서 테스트가 실제로 프로그래밍 속도를 높여주는 경험을 직접 해보지 않고서는 자가 테스트의 진가를 납득하긴 어렵다.
- 24. 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 나는 기능을 추가해야 할 때 테스트부터 작성한다. 얼핏 순서가 뒤바뀐 듯 들리지만, 전혀 그렇지 않다. 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다.
- 25. 구현보다 인터페이스에 집중하게 된다는 장점도 있다 (무조건 좋은 일이다). 게다가 코딩이 완료되는 시점을 정확하게 판단할 수 있다. 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점이다. 출처: 마틴 파울러, 「개정판 | 리팩터링(2판)」, 이복연, 남기혁 역, 한빛미디어(주), 2020, 134p.
- 28. 프로그램을 설계하기 전에 먼저 테스트를 설계하면 어떨까? 어떤 함수가 존재하지 않으면 실패하는 테스트를 만든 다음에 프로그램에서 그 함수를 구현하면 어떨까? 아예 한 줄의 코드도 없어서 실패하는 테스트를 만든 다음에야 프로그램에 그 코드를 추가하는 것은 어떨까?
- 29. 처음에는 어떤 기능성의 존재 여부를 검사하는 테스트를 작성한 후에 단계적으로 그 기능성을 추가해나가는 것은 어떨까? 이런 방식이 개발하던 소프트웨어의 설계에 주는 효과는 무엇일까? 이 같은 포괄적인 테스트 집합의 존재에서 이끌어낼 수 있는 이점은 무엇일까?
- 30. 일차적이고 가장 명백한 효과는 프로그램의 모든 단일 함수가 그 동작을 검증하는 테스트를 갖게 된다는 것이다. 이 테스트 집합은 그 이후의 개발을 위한 뒷밤침이 되어, 프로그래머가 기존의 어떤 기능을 부주의하게 망가뜨릴 때마다 그 사실을 알려준다.
- 31. 프로그래머는 그 과정에서 뭔가 중요한 것을 망가뜨릴 염려 없이 프로그램에 함수를 추가하거나 구조를 바꿀 수 있다. 이 테스트들은 프로그램이 아직 제대로 동작하고 있음을 알려주므로, 프로그래머는 훨씬 자유롭게 프로그램을 수정하거나 개선할 수 있다. 출처: 로버트 C. 마틴, 「클린 소프트웨어」, 이용원, 김정민, 정지호 역, 제이펍, 2020, 34-35p
- 33. 이 세 사람의 공통점은?
- 35. 테스트 주도 개발 없는 애자일이 가능할까?
- 36. The END