개발은 혼자 할 수 있을까? 혹은 개발자들끼리 할 수 있을까? 저는 아니라고 생각합니다. 개발은 개발에 관여된 모든 부서와 종사자들이 함께하는 겁니다. 개발자가 어떻게 하냐에 따라 SE와 QA 그리고 심지어 Sales 까지 하나의 팀으로 공동의 목표를 쫓아 시너지를 낼 수 있습니다. 저는 그렇게 믿습니다.
2018.10.18
OKKYCON: 2018 《The Real TDD - TDD 제대로 알기》
박재성님의 <의식적인 연습으로 TDD, 리팩토링 연습하기> 발표자료입니다.
[연사 소개]
박재성 - SW 교육 전문가 전 NEXT 교수
5년 동안 NEXT에서 학생들을 가르치다 NEXT가 문을 닫으면서 1인 교육 사업을 하고 있다. TDD, 리팩토링 경험이 프로그래머의 삶에 큰 영향을 미칠 것으로 판단해 TDD, 리팩토링을 주제로 교육 과정을 개설했는데 좋은 반응을 얻고 있다.
[발표 소개]
TDD와 리팩토링 역량은 책 몇 권 읽고, 반복적인 연습만 한다고 해서 쌓을 수 있는 역량이 아닙니다. 의식적인 연습을 통해 꾸준히 수련해 나갈 때 점진적으로 향상시킬 수 있습니다. 의식적인 연습을 설계하고, 단계적인 수련을 통해 점진적으로 TDD, 리팩토링 역량을 키워가는 과정에 대해 다룹니다.
http://okkycon.com
This document discusses the observeOn and subscribeOn operators in RxJava. ObserveOn sets the Scheduler on which observers will observe the Observable. SubscribeOn sets the Scheduler on which the Observable will emit items. Several examples are provided to illustrate the difference between the two operators and how they affect the threading of Observable execution. Links to additional documentation resources on RxJava operators are also included.
More Related Content
Similar to Droid knights android test @Droid Knights 2018
개발은 혼자 할 수 있을까? 혹은 개발자들끼리 할 수 있을까? 저는 아니라고 생각합니다. 개발은 개발에 관여된 모든 부서와 종사자들이 함께하는 겁니다. 개발자가 어떻게 하냐에 따라 SE와 QA 그리고 심지어 Sales 까지 하나의 팀으로 공동의 목표를 쫓아 시너지를 낼 수 있습니다. 저는 그렇게 믿습니다.
2018.10.18
OKKYCON: 2018 《The Real TDD - TDD 제대로 알기》
박재성님의 <의식적인 연습으로 TDD, 리팩토링 연습하기> 발표자료입니다.
[연사 소개]
박재성 - SW 교육 전문가 전 NEXT 교수
5년 동안 NEXT에서 학생들을 가르치다 NEXT가 문을 닫으면서 1인 교육 사업을 하고 있다. TDD, 리팩토링 경험이 프로그래머의 삶에 큰 영향을 미칠 것으로 판단해 TDD, 리팩토링을 주제로 교육 과정을 개설했는데 좋은 반응을 얻고 있다.
[발표 소개]
TDD와 리팩토링 역량은 책 몇 권 읽고, 반복적인 연습만 한다고 해서 쌓을 수 있는 역량이 아닙니다. 의식적인 연습을 통해 꾸준히 수련해 나갈 때 점진적으로 향상시킬 수 있습니다. 의식적인 연습을 설계하고, 단계적인 수련을 통해 점진적으로 TDD, 리팩토링 역량을 키워가는 과정에 대해 다룹니다.
http://okkycon.com
This document discusses the observeOn and subscribeOn operators in RxJava. ObserveOn sets the Scheduler on which observers will observe the Observable. SubscribeOn sets the Scheduler on which the Observable will emit items. Several examples are provided to illustrate the difference between the two operators and how they affect the threading of Observable execution. Links to additional documentation resources on RxJava operators are also included.
22. 테스트 코드를 잘 짜기 위해테스트 코드를 잘 짜기 위해
Database에 저장하는 것을 닌텐도에서 해야할까?
API 서버가 해야함.
게임 save 테스트 코드를 실행 할 때마다 API 서버 콜을 해야하나?
아님. 우리는 저장을 성공했다/실패했다를 가정해서 테스트 코드를 만들면 됨
24. 테스트 코드를 잘 짜기 위해
계산기의 구조를 점점 개선해 나갈 거예요.
UI와 Calculate를 분리해서 아예 따로 테스트할 수 있게 하는게 목표예요.
Calculate가 변하더라도 테스트를 작성할 수 있게 만들거예요.
궁극적으로는 Calculate가 없어도 테스트는 성공하고 잘 돌아갈 거예요.
26. 계산기
1. UI 테스트
2. Unit 테스트
a. 4칙 연산 분리. Unit test 진행
3. Interface로 분리
a. Interface 로 나눠서 여러 행동을 정의할 수 있게 변경
4. Server와 함께 춤을
a. 동기/비동기 테스트
5. ViewModel도 함께 춤을
a. 계산 로직 분리
6. 나도 Dagger 좀 해보자
a. 테스트 모듈/프로덕션 모듈 분리
44. Step3 - Interface 로 분리
public interface Step3Calculator {
String calculate(String expression);
int plus(List<String> arguments);
int minus(List<String> arguments);
int multiply(List<String> arguments);
int divide(List<String> arguments);
}
안녕하세요. Android Test 발표를 하게된 정경호입니다. 제 발표를 들으러 와주셔서 너무 감사하구요, 발표 내용이 많은데 나중에 github 과 presentation 동영상이 공유가 될테니 제 발표를 듣고 테스트를 작성하고 싶으신 분은 그 자료들을 참고해주시면 좋을거 같습니다.
발표 설득 대상은 Unit Test 만, QA, 언젠간, 내 코드는
제 발표의 목차는 이렇게 되어있구요. Step by step 에서 6단계의 앱 개발 단계가 있습니다.
언젠가 발표 자료와 github 코드를 보고 적용하도록 하는 것.
Test 코드 짜야할까? 저는 여기에 대한 답으로 이 단어를 지정했습니다. 여기 제가 있습니다. 저는 인간입니다. 인간은 (다음 슬라이드로 넘기며) 실수를 아주 많이합니다.
실수를 아주 많이 합니다. 사실은 정말 끊임없이 합니다.
밥먹듯이 실수를 합니다. 인간은 불완전한 존재이기 때문에 실수를 하고 실수를 통해 성장하기도 합니다. 하지만 실수가 항상 좋지만은 않죠? 어떤 날은 너무 많이 해서 제 자신에게 짜증이 날 때도 있죠. 특히 이런 실수는 언제 많이 나오냐. 중요한 순간에 자주 눈에 띕니다. 다른때는 별로 신경안써도 되는 일이 중요한 순간에는 눈에 너무 잘 띄죠.
제 생각엔 배포 직후인것 같습니다. 시험기간에 뭔가 여기볼까 말까 했던 곳에서 막 시험문제 나왔던 것처럼, 배포하고 나면 뭔가 아 이거 빼먹었다, 아 버그 발견! 이런 경우가 많았던것 같아요.
그래서 항상 이런 상태가 되는 것 같습니다
저는 스타트업에 다니고 있습니다. 이름은 에그번이예요. 챗봇기반 언어 학습 앱입니다. 한국어, 중국어, 일어를 영어, 프랑스어, 스페인어 등으로 가르쳐요. 혹시 한국어가 서툴다 하시는 분은 저희 서비스 써보세요. 도움 될겁니다.
어쨌든 저희도 제품을 개발하고 배포할때, 무언가 붙잡고 싶고 기도하고 싶고 합니다. 왜냐면 스타트업은 일이 너무 많기 때문에 충분할만큼 손으로 테스트하지 못하기 때문이죠.
그럼 다시 처음으로 돌아저희는 열심히 테스트를 짜지만 인간이기 떄문에
인간은 실수를 끊임없이 하기 때문에 테스트 코드가 도움이 됩니다.
박스: 실수를 하지 말자/실수를 빨리 알아차리자
테스트 코드는 확성기와 비슷합니다. 문제가 있으면 빠르게 알아차릴 수 있도록 큰소리로 알려 줍니다. CI 를 이용한다면 슬랙을 통해서 모든 직원에게 동시에 알림을 줄 수도 있겠죠. 손으로 누를 필요없이 컴퓨터가 스스로 실행하기 때문에 피드백을 더 빨리 받을 수 있습니다.
네 저는 인간이라 실수를 안할 수가 없습니다. 그래서 실수를 빨리 알아차리는게 중요하다고 생각했습니다. 만약 여러분도 저와 비슷한 마음이시라면 여기 잘 들어 오셨습니다. 실수 안한다 하시는 분은 옆에 있는 방으로 넘어가서 그거 들으시면 됩니다.
두 번째는 실력 향상입니다. 테스트를 잘 짜긴 위해선 기본기가 중요하게 됩니다. 그 기본기는 바로 desgin 입니다. OOP 에 대한 지식과 경험이 있어야 제대로 test 코드를 짤 수 있고 곧 이는 더 나은 코드 더 확장성이 나은 코드를 만드는데 도움이 됩니다. 그래서 저는
UI Test 부터 합니다.
안드로이드에는 Espresso 라는 test framework 가 존재합니다. 이 프레임워크는 Acceptance Test (인수 테스트, functional test)를 지원합니다. 그냥 처음에 이렇게 시작하는 겁니다. UI 있죠? Button 누르면 어떤 행동이 실행되거나 출력값이 나와야합니다. 그걸 먼저 만듭니다. 숲을 먼저 보는 봅니다.
Unit 테스트로는 전체 앱 flow 를 그리는 것에 한계가 뚜렷합니다. Unit 이라는 단어 자체가 아주 작은 것을 의미하고 있기 때문에 많은 일을 하면 안되죠.
안드로이드에는 Espresso 라는 test framework 가 존재합니다. 이 프레임워크는 Acceptance Test (인수 테스트, functional test)를 지원합니다. 그냥 처음에 이렇게 시작하는 겁니다. UI 있죠? Button 누르면 어떤 행동이 실행되거나 출력값이 나와야합니다. 그걸 먼저 만듭니다. 숲을 먼저 보는 봅니다.
Unit 테스트로는 전체 앱 flow 를 그리는 것에 한계가 뚜렷합니다. Unit 이라는 단어 자체가 아주 작은 것을 의미하고 있기 때문에 많은 일을 하면 안되죠.
안드로이드에는 Espresso 라는 test framework 가 존재합니다. 이 프레임워크는 Acceptance Test (인수 테스트, functional test)를 지원합니다. 그냥 처음에 이렇게 시작하는 겁니다. UI 있죠? Button 누르면 어떤 행동이 실행되거나 출력값이 나와야합니다. 그걸 먼저 만듭니다. 숲을 먼저 보는 봅니다.
Unit 테스트로는 전체 앱 flow 를 그리는 것에 한계가 뚜렷합니다. Unit 이라는 단어 자체가 아주 작은 것을 의미하고 있기 때문에 많은 일을 하면 안되죠.
아 이거 뭐였지
다음 페이지에 넘어가기 전에 뜸들이는?
이런 어려운 걸 잡는다고 해보죠. 잡았어요 힘들게. 위에 피 보면 40밖에 안남았어요. 원래 7500이에요. 잡은 후에 저장을 했어요. 저장은 서버가 하게 되요. 근데 우리가 테스트 코드에 저장했는지 안했는지 알아야할까요? 우리는 저장을 한다는 API 호출 하고 저장이 잘 됐다는 결과를 받으면 되요. 서버팀에서 사용자 데이터를 종이에 적든, 손에 적든, 기억해놓든 알게 뭡니까. 훌륭하신 분이니깐 잘 저장했겠지 믿는 겁니다.
이런 어려운 걸 잡는다고 해보죠. 잡았어요 힘들게. 위에 피 보면 40밖에 안남았어요. 원래 7500이에요. 잡은 후에 저장을 했어요. 저장은 서버가 하게 되요. 근데 우리가 테스트 코드에 저장했는지 안했는지 알아야할까요? 우리는 저장을 한다는 API 호출 하고 저장이 잘 됐다는 결과를 받으면 되요. 서버팀에서 사용자 데이터를 종이에 적든, 손에 적든, 기억해놓든 알게 뭡니까. 훌륭하신 분이니깐 잘 저장했겠지 믿는 겁니다.
우리도 비슷하게 만들어 볼거예요
Calulate 가 아까 젤다에서는 저장이예요.
앱 실행을 보면 이렇게 생겼어요. 더하기 빼기 곱하기 나누기가 되요.
이렇게 설명할 거예요. 한번 발표하고 관심이 생기시면 제 github 프로젝트를 보시면서 따라해보시면 좋을거 같아요. 제가 주석도 조금 달아놨으니 도움이 될거예요.
전체 구조는 이렇구요.
calculate 함수 설명할 것.
안드로이드에는 Espresso 라는 test framework 가 존재합니다. 이 프레임워크는 Acceptance Test (인수 테스트, functional test)를 지원합니다. 그냥 처음에 이렇게 시작하는 겁니다. UI 있죠? Button 누르면 어떤 행동이 실행되거나 출력값이 나와야합니다. 그걸 먼저 만듭니다. 숲을 먼저 보는 봅니다.
Unit 테스트로는 전체 앱 flow 를 그리는 것에 한계가 뚜렷합니다. Unit 이라는 단어 자체가 아주 작은 것을 의미하고 있기 때문에 많은 일을 하면 안되죠.
buttonClick 설명
Matches 설명
Step1Activity가 있습니다.
따로 떼어낼거예요. 테스트를 더 원활히 하기 위해.
이렇게 Calculator 클래스를 만들어서 함수를 옆으로 넘겼어요.
그럼 우리는 UnitTest 를 짤 수 있게 되요. UI 없이 핵심로직, calculate 만 테스트할 수 있어요.
calculate 함수는 똑같구요
이젠 unit test 를 이렇게 작성할 수 있어요. 아깐 4칙연산 테스트를 위해 UI 가 필요했는데 이젠 Calculator 만 필요해요.
훨씬 빠름. 제가 커서 옮기는 것 보다 더 빨라요.
이건 뭐 별거 없음
우리가 앱을 만들 때, 대체로 API server와 통신을 하는 경우가 많아요. 대체로 하죠. 그걸 가정하기 위해 Caclculate 함수를 서버에 넘겨 버렸어요. 나중에 깃헙에서 확인할 수 있구요.
요론 상황들을 테스트 하기 위함입니다. Step4는
그걸 위해 Stream 을 만들건데 Rxjava를 이용할 거예요.
파란 박스에 보면 Step3Activity
빨간 박스는 변경 부분
Calculator 의 구현체는 이렇게
테스트 코드를 짜는데, 빨간색 박스 부분을 보죠. 중요합니다.
서버가 미국에 있을 수도 우주에 있을 수도 있고 서버팀이 막 더해줄수도 있어요.
우리는 실제로 서버에서 언제 응답이 올지 몰라요. 그쵸? 그래서 대충 2초 기다리게 했어요. 일단 빨리 다음으로 가봅시다.
이렇게 테스트를 실행하면 실제로는 테스트가 실패해버려요. 왜냐면 서버 응답이 오기전에 2초가 지났거든요. 이 다음 스텝에서 이걸 해결할거예요.
ViewModel 을 통해 해결해보죠
위에 코드와 비교
아래 calculate 에서 viewModel.calculate() 설명