In this session, we will introduce you to the concept of unit testing and how we can add new features to our application without breaking anything. We will see how we can add unit test cases for each of our components and the importance of it.
Learn how to set up an end-to-end testing framework Cypress Automation Testing Tutorial in an angular app. Also, visit the Github code to set up the project.
Are you eager to migrate your entire codebase to Vue 3 and composition API? Before starting the long journey away from Vue 2.6 you should consider a few intermediate steps:
- compatibility with your dependencies
- tests
- maintainability
- consider a step-by-step migration passing trough Vue 2.7
- what about the Vite/Vitest ecosystem?
In this core java training session, you will learn Collections - Maps. Topics covered in this session are:
• Collections – Maps
• Map Interface
• Map methods
• Mapuse
• Hashmap
• Treemap
• Utilities
For more information about this course visit on this link: https://www.mindsmapped.com/courses/software-development/learn-java-fundamentals-hands-on-training-on-core-java-concepts/
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
In this session, we will introduce you to the concept of unit testing and how we can add new features to our application without breaking anything. We will see how we can add unit test cases for each of our components and the importance of it.
Learn how to set up an end-to-end testing framework Cypress Automation Testing Tutorial in an angular app. Also, visit the Github code to set up the project.
Are you eager to migrate your entire codebase to Vue 3 and composition API? Before starting the long journey away from Vue 2.6 you should consider a few intermediate steps:
- compatibility with your dependencies
- tests
- maintainability
- consider a step-by-step migration passing trough Vue 2.7
- what about the Vite/Vitest ecosystem?
In this core java training session, you will learn Collections - Maps. Topics covered in this session are:
• Collections – Maps
• Map Interface
• Map methods
• Mapuse
• Hashmap
• Treemap
• Utilities
For more information about this course visit on this link: https://www.mindsmapped.com/courses/software-development/learn-java-fundamentals-hands-on-training-on-core-java-concepts/
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
애자일을 제대로 실천하려면 실패와 실수에서 학습하고, 공동의 목적을 이루기 위해 다른 사람들을 도우려는 마음가짐이 필요하다.
고착화된 마인드셋에서 성장 마인드셋으로 바뀌었던 경험을 토대로 고착화된 마인드셋에서 애자일 마인드셋을 얻게 되었는지 살펴보았다.
애자일 마인드셋이 필요한 이유와 어떻게 애자일 마인드셋을 키울 것인지도 알아본다.
Legacy code refactoring video rental systemJaehoon Oh
Legacy Code Refactoring
- 마틴 파울러의 Refactoring 책 1장 예제를 워크샾 형태로 구성했다.
- 레거시 코드인 비디오 렌탈 시스템을 리팩토링 하는 방법을 단계적으로 살펴본다.
- 마이클 페더스의 Characterization Test 방법을 이용해서 Legacy Code 의 테스트를 작성한다.
- 새로운 기능을 추가할 때는 Sprouting Pattern(마이클 페더스가 만든 용어)를 이용해서 기능을 추가한다.
- 코드 스멜을 찾고 코드 스멜을 제거하면서 코드의 설계를 개선한다.
TDD 규칙은 간단하지만, TDD 를 배우는 것은 어렵고, 실천하기는 더 어렵다.
왜 그럴까? TDD 는 설계 방법이기 때문이다. TDD 의 규칙 리듬을 알고 따르려고 해도, 설계 용어들을 모르면 TDD 를 제대로 할 수 없다.
TDD 를 잘 하려면, 설계용어의 의미를 이해하고, 언제 적용하는지도 알아야 한다.
Odin_CCTV based population counting platformSangwook Park
클라우드 기반의 CCTV를 활용한 유동인구 솔루션인 오딘은 소프트웨어 마에스트로 연수 기간동안 기획한 서비스입니다. 자료조사, 프레젠테이션 디자인, 발표, 서비스 기획 등을 담당했으며 머신러닝과 기술을 시장에 거리낌 없이 적용시키는 법에 대해 배울 수 있는 기회였습니다.
리모트콜은 PC화면 원격 공유와 제어를 통해 실시간으로 문제를 해결하는 PC원격지원 솔루션입니다. 다양한 OS(맥, 리눅스, 윈도우)와 모든 부라우저 환경을 지원하며, 강력한 보안을 갖추고 있습니다.리모트콜 도입으로 ROI를 높일 수 있는 비결과 다른 회사는 리모트콜을 어떻게 효율적으로 활용하고 있는지 확인할 수 있습니다.
급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요?
요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다.
그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요?
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다.
(공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.)
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다.
• 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다.
• 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도
출한 내용이 포함되어 있습니다.
1. 앱 성능 진단
• 앱 진단 절차
• 앱 진단 상세 내용
2. 웹 서버 성능 진단
• 웹 진단 절차
• 웹 진단 방향
3. 부하 테스트
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행 방안
• 부하 테스트 전략
• 클라우드 기반 테스트 방안
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
hhjung@onycom.com l 02-6395-7722
1. 인수테스트 주도 개발
( Acceptance Test
Driven Development )
오재훈 (주)넷스루 연구소장
( jaehoon@nethru.co.kr,
ojh420@gmail.com,
https://www.facebook.com/jaehoon.oh.503 )
3. 테스팅 재정의하기
새로운 정의:
- 체킹 : 요구사항 대로 구현되었는지 검사하는 과정
- 테스팅 : 시스템이 요구사항 대로 동작한다고 가정했을 때,
기계적으로 검증할 수 없는 시스템의 동작 방식을
탐색하고 발견하고 배우는 과정
4. Checking
- 이미 가지고 있는 믿음이 있을 때, 그 믿음과 일치하는지 검사하는 과정
- 우리가 알고 있는 시스템의 동작방식을 확인하는 것
- 프로그램이 합의된 사양대로 동작하는지를 확인하는 데 초점을 둔다.
- 결과는 흑백중 하나다.
- 기계적인 검증이 가능하다.
Testing
- 시스템에 대해서 아직 모르는 것을 찾기 위한 활동
- 탐색, 발견, 배움의 과정이다.
- 시스템이 어떻게 동작하는지에 대해 충분히 배우는데 초점을 둔다.
- 결과는 예측할 수 없다.
- 시스템의 행동을 관찰하고, 가치 판단이 개입되기 때문에 기계적 검증이
불가능하다.
테스팅 재정의하기
7. 전통적인 개발 프로세스
1. 현재 개발중인 기능이 어느 정도 진척되었나요? ( 개발 진척도 판단 기준 )
2. 현재 개발중인 기능이 언제쯤 완성이 될까요? ( 개발 완료 판단 기준 )
3. 기능을 검증할 테스트 케이스를 언제 설계 하나요?
4. 개발자들이 테스트케이스를 알고 있나요?
5. 테스트 언제 실행 하나요?
6. 테스트를 누가 수행 하나요?
7. 발견된 버그에 대한 정보들을 어떻게 주고 받나요?
8. 코드 구현 - 테스트 수행 - 버그 전달에 걸리는 시간은 얼마나 되나요?
9. 버그수정후 테스트를 재수행했을 때 회귀결함이 얼마나 많이 발생하나요?
10. 프로그래머와 테스트는 어떻게 협력하나요?
11. 어떤 비용들이 발생하고 있나요?
12. ...
이 질문들에 답해보세요.
15. 인천공항 주차장 요금표
http://www.airport.kr/pa/ko/d/3/2/4/index.jsp
※ 단기주차장의경우 주말(금·토·일),법정 공휴일, 동·하계 성수기(7월1일~8월31일, 12월1일~익년1월31일) 기간에는 상기 성수기
요금을 적용
구 분
최초 방문 시 2회차
방문시
3회차 방문부터
(변경요금)비성수기 성수기
단기주차장 소형
(시간당 2,400원)
기본 30분 1,200원
추가 15분 600원
(시간당 2,800원)
기본 30분 1,400원
추가 15분 700원
(시간당 2,400원)
기본 30분 1,200원
추가 15분 600원
일 12,000원 일 14,000원 일 18,000원 일 24,000원
장기주차장
(주차타워
포함)
소형
(시간당 1,000원)
일 9,000원
대형
(30분당 1,200원)
일 12,000원
화물터미널
주차장
소형
최초 45분 무료
추가 15분 500원
일 10,000원
대형
최초 45분 무료
추가 15분 600원
일 12,000원
16. 이 상태에서 프로그래머가 구현을 시작한다면 어떤
일이 생길까요?
요구사항을 다르게 이해할 수 있는 가능성이
있을까요?
인수테스트 주도 개발 (ATDD)
17. 요구사항을 다르게 이해할 가능성들
고객이 2016년 3월 16일 0시 0분 0초에 주차장에 들어와서, 30분 59초에 주차장을
나갔다. 몇 분으로 계산해야 하는가? ( 초를 어떻게 처리해야 하는가? )
전날 23시 50분에 주차장에 들어와서, 다음날 0시 20분에 주차장을 나가면
주차요금은 얼마인가? (하루의 기준)
고객이 2016년 3월 17일(목) 23시에 주차장에 들어와서 성수기 요금을 받는 18일
(금요일) 오전 01 시에 주차장을 나갔다면 요금은 얼마인가? ( 성수기/비수기
혼합시 계산방법 )
고객이 2016년 3월 17일(목) 23시 59분에 주차장에 들어와서 성수기 요금을 받는
18일(금요일) 오전 00 시 1분에 주차장을 나갔다면 요금은 얼마인가? (
성수기/비수기 혼합시 계산방법 )
...
18. ATDD 개발 과정
예제로
명세하기
예제 정제하기
실행 가능한
명세 만들기
Growing Object Oriented Software Guided by Tests by Steve Freeman & Nat Pryce
19. 예제로 명세하기
고객(혹은 대리인), 프로그래머, 테스터가
협력해서 명세를 작성한다.
추상적인 요구사항을 동일하게 이해하기
위해서 객관적이고 구체적인 예제를
이용한다.
프로
그래
머
테스
터
고객
20. 명세 정제하기
예제가 과도하게 많이 작성된 경우
관련성이 적은 정보를 제거하고
개발과 테스트에 필요한 정보만을 남긴다.
23. Cucumber 를 이용한 Specification 작성
Feature: 기능을 간략히 서술
기능에 대한 상세 설명
Scenario: 시나리오의 제목
Given 시나리오를 테스트하기 전의 시스템 상태를 기술(사전조건)
When 시스템에 발생시켜야 하는 이벤트를 기술
Then 이벤트가 발생했을 때 시스템이 사후상태를 기술(사후조건)
24. 실행 가능한 Specification 만들기
Scenario Outline: [비수기] 단기 주차장에 주차한 경우 주차 요금을 계산한다.
When 방문객이 비수기에 단기 주차장에 <duration>동안 주차한다.
Then 방문객은 주차요금으로 <cost>원을 지불해야 한다.
Examples:
| duration | cost |
| 1분 | 1200 |
| 30분 | 1200 |
| 31분 | 1800 |
| 45분 | 1800 |
| 1시간 | 2400 |
| 5시간 | 12000 |
| 5시간 1분 | 12000 |
| 1일 | 12000 |
| 1일 1분 | 13200 |
| 1일 31분 | 13800 |
| 2일 1분 | 25200 |
| 3일 1분 | 37200 |
25. Cucumber 명세 예제
Feature: 인천공항 주차장의 주차 요금을 계산한다.
여기에 사용자 스토리를 적어주세요...
Scenario Outline: [비수기] 단기 주차장에 주차한 경우 주차 요금을 계산한다.
When 나는 평일에 단기 주차장에 <duration>동안 주차한다.
Then 나는 주차요금으로 <cost>원을 지불해야 한다.
Examples:
| duration | cost |
| 1분 | 1200 |
| 30분 | 1200 |
| 31분 | 1800 |
| 45분 | 1800 |
| 1시간 | 2400 |
| 5시간 | 12000 |
| 5시간 1분 | 12000 |
| 1일 | 12000 |
| 1일 1분 | 13200 |
| 1일 31분 | 13800 |
| 2일 1분 | 25200 |
| 3일 1분 | 37200 |
26. Cucumber Test 코드 작성
package com.inchon.parking;
import org.junit.runner.RunWith;
import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
@RunWith(Cucumber.class)
public class ShortTermParkingLotTest {
}
27. Cucumber Step Definitions
public class ShortTermParkingLotStepDefinitions {
@When("^방문객이 평일에 단기 주차장에 (.+)동안 주차한다.$")
public void 방문객이_평일에_단기_주차장에_분동안_주차한다(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@Then("^방문객은 주차요금으로 (d+)원을 지불해야 한다.$")
public void 방문객은_주차요금으로_원을_지불해야_한다(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@When("^방문객이 주말에 단기 주차장에 (.+)동안 주차한다.$")
public void 방문객이_주말에_단기_주차장에_분동안_주차한다(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
...
}
28. Cucumber 테스트 자동화 아키텍처
Examples
Test Framework
Glue Code
Support Code
Application
Under Test
*.feature
Cucumber
Cucumber Test
Step Definitions
Support Code
Production
Code
31. 테스트 시나리오 품질
도출된 테스트 시나리오는
1. 비지니스 규칙을 기술하고 있는가?
2. 테스트 시나리오의 의도가 잘 드러나는가?
3. 쉽게 이해할 수 있는가?
4. 유지보수 비용이 많이 들지 않는가?
32. 테스트 시나리오 기술 수준
https://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
33. 테스트 시나리오 기술 수준
시니라오 기술
수준
설명
Technical Activity
● 시스템을 구현한 기술을 기준으로 테스트 시나리오를 작성하는 방법
● 테스트 시나리오에 기술과 관련된 용어들이 나타난다.
● 구현과 관련된 기술이 바뀌거나 시스템을 사용하는 순서가 바뀌면 테스트
시나리오를 수정해야 한다.
작업 흐름
( Workflow )
● 사용자가 시스템을 사용하는 작업의 흐름을 기준으로 테스트 시나리오를
작성하는 방법
● 테스트 시나리오에서 기술과 관련된 용어들이 나타나지 않기 떄문에
기술이 바뀌어도 테스트 시나리오는 바뀌지 않는다.
● 작업 흐름이 바뀌는 경우에는 테스트 시나리오를 변경해야 한다.
비지니스 규칙
( Business Rule )
● 비즈니스 규칙이 명확히 드러나도록 테스트 시나리오를 작성하는 방법
● 구현과 관련된 기술이 바뀌어도 테스트 시나리오를 수정하지 않아도 된다.
● 작업 흐름이 바뀌어도 테스트 시나리오를 수정하지 않아도 된다.
34. Technical Activity 로 기술하기
1. 인천공항 주차 요금 계산기 페이지로 접속한다.
2. 도착 예정 날짜 입력창에 “2015-10-14” 로 입력한다.
3. 도착 예정 시각 입력창에 “10”시로 입력한다.
4. 도착 예정 분 입력창에 “0” 분으로 입력한다.
5. 출차 예정 날짜 입력창에 “2015-10-14” 로 입력한다.
6. 출차 예정 시각 입력창에 “10” 시로 입력한다.
7. 출차 예정 분 입력창에 “30” 분으로 입력한다.
8. 차종 선택 라디오버튼에서 차종을 “소형" 으로 선택한다.
9. 주차장 선택 라디오버튼에서 주차장을 “단기"로 선택한다.
10. “요금계산하기" 버튼을 클릭한다.
11. 주차 요금 계산 결과 텍스트를 읽어서 값이 1200원인지 확인한다.
35. 작업흐름(Workflow) 로 기술하기
1. 인천 공항 주차 요금 계산 페이지에 접속한다.
2. 도착 예정 시각을 “2015-10-14 10:00” 으로 설정한다.
3. 출차 예정 시각을 “2015-10-14 10:30” 으로 설정한다.
4. 차종을 소형으로 선택한다.
5. 요금을 계산을 요청한다.
6. 계산 결과가 “1200” 원이어야 한다.
36. 비지니스 규칙으로 기술하기
Scenario: 평일 단기 주차장의 소형차 주차 요금을 계산한다.
When 고객이 평일에 소형차를 단기 주차장에 1분간 주차한다.
Then 고객은 주차요금으로 1200원을 지불해야 한다.
37. ATDD 도입으로 인한 변화
항목 Waterfall ATDD
의사소통과 협력 요구사항을 다르게 해석할 수 있음
개발자-테스터간 소통량이 적음
개발 막바지에 협력
고객-프로그래머-테스터간의 공통의
이해
프로그래머-테스터간의 소통량이
많아짐
개발 과정에서 수시로 협력해야 함
테스트 설계 시점 구현 진행이 완료되기 전 요구사항 명세 공유시
테스트 설계 방법 QA 팀에서 독자적으로 작업 고객, QA, 프로그래머 공동 작업
테스트 시나리오 작성
시점
개발이 완료될 무렵 개발전
인수테스트 실행 시점 프로그래머가 구현 종료후 테스터가
실행
프로그래머가 구현시 수시로 실행
진척도 판단 기준 프로그래머의 직관(감?) 인수테스트 통과 비율
완료 판단 기준 프로그래머의 직관(감?) 인수테스트 통과 비율 100%
역할의 변화 프로그래머 :
- 구현만 담당
테스터 :
프로그래머 :
- 구현
- 체킹 : 스펙대로 구현되어
38. ATDD 도입으로 얻을 수 있는 것들
● 요구사항은 추상적이어서 경험과 생각의 차이로 다르게
해석할 수 있지만, 예제는 구체적이고 객관적이기
때문에 다르게 해석하기 어렵다.
● 구체적인 예제를 이용해서 고객-프로그래머-테스터가
요구사항을 동일하게 이해하게 된다.
● 프로그래머가 요구사항을 오해해서 발생하는 버그를
미연에 방지할 수 있다.
● 프로그래머-테스터간에 발생할 수 있는 갈등을 방지할
수 있다.