2016년 05월에 Code states 에서 발표한 내용. TDD,BDD, CI, CD 의 개념을 간단히 소개. Cucumber, mocha, super test 등 node.js 에서 사용할 수 있는 library 소개.

1. TEST
정경호

2. • TDD
• BDD
• Unit test - mocha
• Integration Test - mocha
• Acceptance Test - super test
• End-to-end Test
• Code coverage reports - Istanbul
• Continuous Integration - travis
• Continuous Delivery - AWS CodePipeline, Solano CI

3. Test Driven Development
개발
TDD
테스트 실패 테스트 성공 리팩토링
반복

4. Test Driven Development - 장점
• 디버깅 시간의 단축
• 디자인 개선
• 테스트 가능한(Testable) 코드를 작성. Coupling 감소.
• 리팩토링의 용이성
• 테스트 코드 없이 리팩토링을 할 수 있을까?

5. Test Driven Development - 단점
• TDD 어렵다.
• 지식 습득은 적다. 하지만 TDD를 하기가 매우 어려움. 처음에 막막함을
느낀다. 수영처럼 연습이 많이 필요함.

6. DEMO
“a + b 를 해주는 객체”

7. Behavior Driven Development
BDD
테스트 실패 테스트 성공 리팩토링
반복
TDD
테스트 실패 테스트 성공 리팩토링
반복
User story
User story
둘의 프로세스는 같다.
차이점은 User story 의 유무이다.

8. Behavior Driven Development
Format[edit]
A team at Connextra developed the traditional user-story template in 2001:[4]
"As a <role>, I want <goal/desire> so that <benefit>"
Mike Cohn, a well-known author on user stories, regards the "so that" clause as
optional:[5]
"As a <role>, I want <goal/desire>"

9. Behavior Driven Development
Story: User logging in
As a user
I want to login with my details
So that I can get access to the site
Scenario: User uses wrong password
Given a username ‘name’
And a password ‘password’
When the user logs in with username and password
Then the login form should be shown again

10. Behavior Driven Development - 장점
• 비 개발자도 읽을 수 있는 ‘User story’ 기반의 아웃풋
• https://github.com/moltak/node_cucumber_sample

11. features
step_definition

13. DEMO
“사용자는 100원을 입금한다. 200원을 얻기 위해.”

14. TDD/BDD 차이
• Unit (method, function)
• Behavior(기대 행동) user story, scenario

15. Unit Test
단일 기능 위주의 테스트

16. Integration Test
서로 다른 시스템을 이용하는 다양한 모듈의 결합된 기능을 테스트

17. Acceptance Test
Web page, Web browser를 이용한 end user가 사용한다고 생각하고 테
스트. Scenario 검증.

18. Acceptance Test
Acceptance testing seems to be split into two types:
Standard acceptance testing involves performing tests on the full system (e.g. using your web
page via a web browser) to see whether the application's functionality satisfies the specification.
E.g. "clicking a zoom icon should enlarge the document view by 25%." There is no real
continuum of results, just a pass or fail outcome.
Also, in agile software development, user acceptance testing involves creating tests to mirror the
user stories created by/for the software's customer during development. If the tests pass, it
means the software should meet the customer's requirements and the stories can be considered
complete. An acceptance test suite is basically an executable specification written in a domain
specific language that describes the tests in the language used by the users of the system.
http://stackoverflow.com/questions/4904096/whats-the-difference-between-unit-functional-acceptance-and-integration-test

19. End-to-end Test
• 모든 테스트 + 시스템 + 배포
• End user가 서비스 제공자가 제공하는 기능을 제대로 사용할 수 있는지
OS, Container 등 모든 것을 테스트. 빌드, 배포, 웹서비스의 경우에는 웹
서버까지

20. End-to-end Test
End-to-end testing involves ensuring that that integrated components of an application
function as expected. The entire application is tested in a real-world scenario such as
communicating with the database, network, hardware and other applications.
For example, a simplified end-to-end testing of an email application might involve:
• Logging in to the application
• Accessing the inbox
• Opening and closing the mailbox
• Composing, forwarding or replying to email
• Checking the sent items
• Logging out of the application
http://stackoverflow.com/questions/4904096/whats-the-difference-between-unit-functional-acceptance-and-integration-test

21. Code Coverage
• 테스트가 코드를 얼마나 커버하였는가 를 나타내는 지표.
• Statement coverage: 실행 코드라인이 한번 이상 실행
• Function coverage: function (or subroutine)이 한번 이상 실행.
• Condition coverage: if 구문이 true/false 모두 실행 되었을 때.
• Branch coverage: 분기 안의 모든 분기나, 모든 결과에 대해 실행되었을
때.

22. Code Coverage - istanbul

23. Code Coverage - istanbul

24. Continuous Integration

25. Continuous Integration
I’m a project owner I’m project
coding, testing
혼자일때 그냥 대충해도 별로 상관없음

26. Continuous Integration
I’m a project owner I’m project
coding, testing
다른 사람과 같이 작업하면?

27. Continuous Integration
I’m a project owner I’m project
coding, testing
사람이 더 많아지면?

28. Continuous Integration
I’m a project owner I’m project
coding, testing
사람이 더 많아지면?
코드를 어떻게 유지할 것인가?

29. Continuous Integration
I’m a project owner I’m project
coding, testing
코드의 안정성은 어떻게 지킬 것인가?
사람이 더 많아지면?
코드를 어떻게 유지할 것인가?

30. “Continuous Integration”

31. Continuous Integration
I’m a project owner I’m project
coding, testing

32. Continuous Integration
I’m a project owner I’m project
git push
start
coding, testing

33. Continuous Integration
I’m a project owner I’m project
CI
git push
git pull
npm test
start
coding, testing

34. Continuous Integration
I’m a project owner I’m project
CI
git push
git pull
npm test
send notification
start
coding, testing

35. Continuous Integration
I’m a project owner I’m project
merge
CI
git push
git pull
npm test
send notification
start

36. Continuous Integration

37. Continuous Integration

38. Continuous Integration

39. “Continuous Integration”
많은 사람과 동시에 작업을 하더라도 안정적으로 코드를 유지할 수 있음.

40. Continuous Delivery

41. Continuous Delivery
잘 할 수 있을까?
짧은 출시기간
빠른 배포시간
쉬운 백업, 복구
지속적인 출시

42. Continuous Delivery
질문! 배포 어떻게 하고 계세요?

43. “AWS CodePipeline”

44. Continuous Delivery
git pull
npm test
deploy to staging
deploy to production

45. DEMO
“Hello code states!”

46. Q&A