Machine_웅_Note

예시 => isVaild 를 테스트 하게되면 isVaild는 프라이빗이기 때문에,, public으로 바꾸지 않아야 한다. => isVaild 정책의 변경에 따라 저 코드는 문제가 될수 있다. => set , process , assert 하는 구조는 앞으로도 계속 되는 구조임으로 기억하자. => 트렌젝션을 직접 만들어서 처리를 해보는 것이 좋다. => 테스트를 통해서 나올 결과를 가지고 판단을 해야하지, 나온 결과를 또다른 조작을 통해서 판단 검증해서는 안된다. => 위에 예시에서는 createUser로 만든 계정을 아래서 db에 넣음으로써 검증을 하는 또다른 조작을 하고 있다. 완결성 : 테스트는 전부를 가지고 있어야한다, 완성되어있어야 한다. => 그 테스트케이스 안에는 테스트하고자 하는 것을 정확일..

1. 왜 테스트가 중요한가? 2. 안드로이드 테스트 종류 3. 무엇을 테스트 해야할까? ( baby step ) 4. 구글은 어떻게 테스트 하는가 ? 5. 좋은 테스트의 조건 6. 외부 의존성 처리의 원칙 7. 테스팅 안티패턴 1. 아키텍쳐 관점에서 테스트를 어떻게 구현 해야할지 2. 좋은 아키텍처를 구축하기 위해서는 전제조건으로 테스트를 어떻게 구현해야할지 알아본다 3. 테스트의 원칙 1. 왜 테스트가 중요한가? 1) 현실적인 필요성 : QA가 보다 생산적으로 일할 수 있다. 2) 좋은 설계를 촉진 : test case 를 통해서 api 를 변경시 사용성의 차이를 즉시 알 수 있다. => 개방폐쇄 원칙, 단일책임원칙 등 필요없는 의존성 문제를 해결 할 수있음. 3) 코딩 생산성 : 확신을 가지고 작업가..

3. 모바일 클린 아키텍쳐 * 왜 이렇게 하는 가에 대해서 집중해서 보도록 하자 가장 높은 수준의 계층 - 도메인 계층 (유스케이스) : 비지니스 요구를 충족하기 위한 부분 * 엔티티 - 업무 룰의 정의이다 ( 데이터 저장소가 아닌다 ) * 유스케이스 - 기술적인 부분이 아니라 비지니스 로직부분 이다. 도메인 관점의 비지니스로직 : 개발자가아니라, 기획자 등이 알아야 하는 비지니스 로직을 말한다.

1. 복잡성 제거 - 좋은 설계를 위한 첫 걸음 1) 복잡성을 조장하는 요인 세가지 - 의존성 ( 코드가 독립적으로 이해되고, 수정 될 수 없을때. -> 없앨수는 없으나 최소화해야함. ) - 불명확성 ( 중요한 정보가 불명확할 때 - 특정 메소드의 인풋 아웃풋이 불명확 , 과정이 불명확 ) - 전술적 프로그래밍 ( 전략적 프로그래밍 ) ( 빨리 완성하기 - 지금 있는 문제만 고려하고 수정하는 문제 ) 2) 복잡성을 낮추는 방법 추상화 - 정보에 대한 간단한 시나리오나, 시놉시스만 알면되는 것 깊은 모듈 - 모듈이 있다고 가정할 때에 사용자가 알아야 하는 것은 단순하게 사용할수 있는 메서드나 클래스여야 한다 - 하나의 기능을 사용하기 위해 계속해서 모듈의 메서들을 호출하는 것은 얕은 모듈이고 깊이가 얕고 ..

SOLID 2000년대 초반 로버트C. 마틴이 객체 지향프로그래밍 및 설계에 대한 SOLID 라는 5가지 원칙을 소개함 1. 단일 책임 원칙 ( Single Responsibility Principle ) - 단일 책임은 어떤 클래스나 모듈 또는 메서드가 단 하나의 기능을 가져야 한다는 뜻. => 어떤 변경 사항이 발생하더라도 그 변경 사항에 대한 책임이 있는 부분만 수정하면 된다. ex ( 분석 + 서버전송 ) => (분석) ( 서버전송 ) 2. 개방 - 폐쇄 원칙 ( Open Closed Principle ) - 시스템의 구조를 올바르게 구성하여, 변경사항이 발생하더라도 다른코드나, 모듈에 영향이 없도록 해야한다. => 확장성을 높이고, 수정에는 폐쇄적이어야 한다. 3. 리스코프 치환 원칙 ( Lis..