may 05 test_code_states

46
TEST 정경호

Upload: kyungho-jung

Post on 06-Apr-2017

54 views

Category:

Software


1 download

TRANSCRIPT

TEST정경호

• 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

Test�Driven�Development

개발

TDD

테스트�실패 테스트�성공 리팩토링

반복

Test�Driven�Development�-�장점

• 디버깅�시간의�단축�

• 디자인�개선�

• 테스트�가능한(Testable)�코드를�작성.�Coupling�감소.�

• 리팩토링의�용이성�

• 테스트�코드�없이�리팩토링을�할�수�있을까?

Test�Driven�Development�-�단점

• TDD�어렵다.�

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

DEMO

“a�+�b�를�해주는�객체”�

Behavior�Driven�Development

BDD

테스트�실패 테스트�성공 리팩토링

반복

TDD

테스트�실패 테스트�성공 리팩토링

반복

User storyUser story

둘의�프로세스는�같다.��차이점은�User�story�의�유무이다.

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>"

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

Behavior�Driven�Development�-�장점

• 비�개발자도�읽을�수�있는�‘User�story’�기반의�아웃풋�

• https://github.com/moltak/node_cucumber_sample

features

step_definition

DEMO

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

TDD/BDD�차이

• Unit�(method,�function)��

• Behavior(기대�행동)�user�story,�scenario�

Unit�Test

단일�기능�위주의�테스트

Integration�Test

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

Acceptance�Test

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

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

End-to-end�Test

• 모든�테스트�+�시스템�+�배포�

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

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

Code�Coverage

• 테스트가�코드를�얼마나�커버하였는가�를�나타내는�지표.�

• Statement�coverage:�실행�코드라인이�한번�이상�실행�

• Function�coverage:�function�(or�subroutine)이�한번�이상�실행.�

• Condition�coverage:�if�구문이�true/false�모두�실행�되었을�때.�

• Branch�coverage:�분기�안의�모든�분기나,�모든�결과에�대해�실행되었을�때.

Code�Coverage�-�istanbul

Code�Coverage�-�istanbul

Continuous�Integration

Continuous�Integration

I’m a project owner I’m projectcoding, testing

혼자일때�그냥�대충해도�별로�상관없음

Continuous�Integration

I’m a project owner I’m projectcoding, testing

다른�사람과�같이�작업하면?

Continuous�Integration

I’m a project owner I’m projectcoding, testing

사람이�더�많아지면?

Continuous�Integration

I’m a project owner I’m projectcoding, testing

사람이�더�많아지면?코드를�어떻게�유지할�것인가?

Continuous�Integration

I’m a project owner I’m projectcoding, testing

코드의�안정성은�어떻게�지킬�것인가?

사람이�더�많아지면?코드를�어떻게�유지할�것인가?

“Continuous�Integration”�

Continuous�Integration

I’m a project owner I’m projectcoding, testing

Continuous�Integration

I’m a project owner I’m project

git push

start

coding, testing

Continuous�Integration

I’m a project owner I’m project

CIgit push

git pull

npm test

start

coding, testing

Continuous�Integration

I’m a project owner I’m project

CIgit push

git pull

npm test

send notification

start

coding, testing

Continuous�Integration

I’m a project owner I’m projectmerge

CIgit push

git pull

npm test

send notification

start

Continuous�Integration

Continuous�Integration

Continuous�Integration

“Continuous�Integration”�

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

Continuous�Delivery

Continuous�Delivery

잘�할�수�있을까?

짧은�출시기간

빠른�배포시간

쉬운�백업,�복구

지속적인�출시

Continuous�Delivery

질문!�배포�어떻게�하고�계세요?

“AWS�CodePipeline”�

Continuous�Delivery

git pull

npm test

deploy to staging

deploy to production

DEMO

“Hello�code�states!”�

Q&A