티스토리

세상을 바꾸는 개발자

검색하기

블로그 홈

세상을 바꾸는 개발자

healthcoding.tistory.com/m

세상을 바꾸는 개발자

구독자: 5

방명록 방문하기

주요 글 목록

Compose 공식문서정리 - Theming Material Design 3 in Compose제트팩 컴포즈는 머티리얼 디자인의 차세대 진화 버전인 머티리얼 디자인 3를 구현합니다. 머티리얼 3에는 업데이트된 테마, 컴포넌트 및 동적 색상과 같은 머티리얼 유 개인화 기능이 포함되어 있으며, 안드로이드 12 이상의 새로운 비주얼 스타일 및 시스템 UI와 조화를 이루도록 설계되었습니다. 참고: "머티리얼 디자인 3", "머티리얼 3", "M3"라는 용어는 서로 바꿔서 사용할 수 있습니다. 기존 머티리얼 디자인 사양 및 해당 androidx.compose.material 라이브러리는 "머티리얼 디자인 2", "머티리얼 2" 또는 "M2"로 불립니다. 아래에서는 Reply 샘플 앱을 예로 들어 머티리얼 디자인 3 구현을 보여줍니다. 응답 샘플은 전적으로.. 공감수 2 댓글수 0 2024. 5. 18.
Compose 공식문서정리(3) - Thinking in Compose 선언적 프로그래밍 패러다임 지금까지 안드로이드 뷰 계층 구조는 UI 위젯의 트리로 표현할 수 있었습니다. 사용자 상호작용 등으로 인해 앱의 상태가 변경되면 현재 데이터를 표시하기 위해 UI 계층구조를 업데이트해야 합니다. UI를 업데이트하는 가장 일반적인 방법은 findViewById()와 같은 함수를 사용하여 트리를 탐색하고 button.setText(String), container.addChild(View) 또는 img.setImageBitmap(Bitmap) 같은 메서드를 호출하여 노드를 변경하는 것입니다. 이러한 메서드는 위젯의 내부 상태를 변경합니다. 뷰를 수동으로 조작하면 오류가 발생할 가능성이 높아집니다. 데이터가 여러 곳에 렌더링되는 경우 데이터를 표시하는 뷰 중 하나를 업데이트하는 것을.. 공감수 0 댓글수 0 2024. 5. 17.
Compose 공식문서정리(2) - Set up Compose for an existing app(컴포즈 사용하기) 컴포즈 gradle 설정Compose를 사용하려면 먼저 프로젝트에 몇 가지 빌드 구성을 추가해야 합니다. 앱의 build.gradle 파일에 다음 정의를 추가합니다 android { buildFeatures { compose = true } composeOptions { kotlinCompilerExtensionVersion = "1.5.13" }} 몇 가지 주의해야 할 사항1. Android BuildFeatures 블록 내에서 compose 플래그를 true로 설정하면 컴파일 기능이 활성화됩니다.2. ComposeOptions 블록에 정의된 Kotlin 컴파일러 확장 버전 관리는 Kotlin 버전 관리와 연동됩니다. 호환성 맵을 참조하여 프로젝트의 Ko.. 공감수 0 댓글수 0 2024. 5. 16.
Compose 공식문서정리(1) - Introduction Compose를 도입해야 하는 이유Jetpack Compose는 네이티브 UI를 빌드하기 위한 Android의 최신 툴킷입니다. 더 적은 코드, 강력한 도구, 직관적인 Kotlin API로 앱에 생명을 불어넣어 Android에서 UI 개발을 간소화 및 가속화합니다. 안드로이드 UI를 더 빠르고 쉽게 빌드할 수 있습니다. Compose를 개발하는 동안 다양한 파트너와 협력하여 이러한 모든 이점을 직접 경험하고 몇 가지 핵심 사항을 공유했습니다. Less code 코드를 적게 작성하면 개발의 모든 단계에 영향을 미칩니다. 작성자는 테스트 및 디버깅할 코드가 줄어들어 당면한 문제에 집중할 수 있고 버그 발생 가능성이 줄어들며, 검토자나 관리자는 읽고, 이해하고, 검토하고, 유지 관리해야 할 코드가 줄어듭니다... 공감수 0 댓글수 0 2024. 5. 15.
[이펙티브 코틀린] 단위 테스트를 만들어라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 단위테스트를 만들어라 코드를 안전하게 만드는 다양한 방법이 있지만 가장 궁극적인 방법은 다양한 종류를 테스트 하는 것이다 하지만 비즈니스적인 관점의 테스트는 개발자 관점에서 애플리케이션 내부적으로 올바르게 작동하는지 확인하는 것이 아니라, 사용자의 관점에서 애플리케이션 외부적으로 제대로 동작하는지 확인하는 것이 목표이다 그렇기 때문에 개발자에게 유용하지만 충분하지는 않다. 이러한 문제.. 공감수 0 댓글수 0 2023. 7. 20.
[이펙티브 코틀린] 코틀린의 안정성 - use를 사용하여 리소스를 닫아라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - use 를 사용하여 리소스를 닫아라 더 이상 필요하지 않을 때 close 메서드를 사용해서 명시적으로 닫아야하는 리소스가 있다 예를 들어 - InputStream, OutputStream - java.sql.Connection - soket, Scanner 등등 이러한 리소스들은 AutoCloseable 을 상속받는 Closeable 인터페이스를 구현하고 있다 이러한 모든 리소스들은 .. 공감수 0 댓글수 0 2023. 7. 19.
[이펙티브 코틀린] 코틀린의 안정성 - 적절하게 null 을 처리하라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 적절하게 null 을 처리하라 기본적으로 nullable 타입은 세 가지 방법으로 처리한다 ?., 스마트 캐스팅, Elvis 연산자 등을 활용해서 안전하게 처리한다. 오류를 throw 한다 함수 또는 프로퍼티를 리펙터링해서 nullable 타입이 나오지 않게 바꾼다 null 을 처리할때 가장 좋은 방법은 스마트캐스팅이나 elvis 연산자를 사용해서 처리하는게 가장 좋지만 requir.. 공감수 0 댓글수 0 2023. 7. 18.
[이펙티브 코틀린] 방어적 프로그래밍 vs 공격적 프로그래밍 방어적 프로그래밍 모든 가능성을 올바른 방식으로 처리하는 것(예를 들어 null일때는 출력하지 않기 등) 방어적 프로그래밍은 코드가 프로덕션 환경으로 들어갔을때 발생할 수 있는 수많은 것들로부터 프로그램을 방어해서 안정성을 높히는 방법을 나타내는 굉장히 포괄적인 용어 상황을 처리할 수 있는 올바른 방법이 있을때 굉장히 좋다 공격적 프로그래밍 모든 상황을 안전하게 처리하는 것은 불가능하기 때문에 등장 예상하지 못한 상황이 발생했을때, 이러한 문제를 개발자에게 알려서 수정하게 만드는 것 require, check, assert 가 공격적 프로그래밍을 하기 위한 도구 --> 둘은 충돌되는 것처럼 보이지만, 둘다 안전을 위해 모두 필요하기 때문에 적절하게 사용해야한다 참고 : 이펙티브 코틀린 https://ww.. 공감수 0 댓글수 0 2023. 7. 17.
[이펙티브 코틀린] 결과 부족이 발생할 경우 null과 failure를 사용하라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 결과 부족이 발생할 경우 null과 failure를 사용하라 함수가 원하지않는 경과랄 만들어내는 경우에 이를 처리하는 2가지 매커니즘 1. null 또는 실패를 나타내는 sealdclass(failure 등) 리턴 2. 예외를 throw 한다 -> 지양해야하는 경우 예외는 정보를 전달하는 방법으로 사용해서는 안된다 많은 개발자가 예외가 전파되는 과정을 제대로 추적하지 못한다 코틀린의.. 공감수 0 댓글수 0 2023. 7. 16.
[이펙티브 코틀린] 코틀린의 안정성 - 사용자 정의 오류보다는 표준 오류를 사용하라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 사용자 정의 오류보다는 표준 오류를 사용하라 표준라이브러리의 오류는 대부분의 개발자들이 알고 있으므로 이를 재사용하는 것이 좋다 잘 만들어진 규약을 가진 널리 알려진 요소를 재사용하면, 다른 사람들이 API를 더 쉽게 배우고 이해할 수 있다 일반적으로 사용되는 예외 IlegalArgumentException, IllegalStateException : require, check를 이용.. 공감수 0 댓글수 0 2023. 7. 15.
[이펙티브 코틀린] 코틀린의 안정성 - 최대한 플랫폼 타입을 사용하지 말라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 최대한 플랫폼 타입을 사용하지 말라 자바에서는 모든 것이 nullable일 수 있으므로 최대한 안전하게 접근한다면, 이를 nullable로 가정하고 다뤄야한 다 코틀린에서는 어떤 메서드는 null을 리턴하지 않을 것이 확실할 수 있다. 이러한 경우에는 마지막에 !! 을 붙인다 플랫폼 타입이란 다른 프로그래밍 언어에서 전달되어서 nullable인지 아닌지 알 수 없는 타입을 말한다 코틀.. 공감수 0 댓글수 0 2023. 7. 12.
[이펙티브 코틀린] 코틀린의 안정성 - inferred 타입으로 리턴하지 말라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - inferred 타입으로 리턴하지 말라 타입을 확실하게 지정해야 하는 경우에는 명시적으로 타입을 지정해야 한다는 원칙을 가지고 있어야한다 이는 굉장히 중요한 정보이다, 안전을 위해서 외부 API를 만들때는 반드시 타입을 지정하고, 이렇게 지정한 타입을 특별한 이유와 확실한 확인 없이는 제거하지 말아야한다 inferred 타입은 프로젝트가 진전될 때, 제한이 너무 많아지거나 예측하지 못.. 공감수 0 댓글수 0 2023. 7. 12.
[이펙티브 코틀린] 코틀린의 안정성 - 변수의 스코프를 최소화 하라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 변수의 스코프를 최소화 하라 상태를 정의 할 때는 변수와 프로퍼티의 스코프를 최소하하는 것이 좋다 프로퍼티 보다는 지역 변수를 사용하는 것이 좋다 최대한 좁은 스코프를 갖게 변수를 사용해야한다 반복문 내부에서만 변수가 사용된다면, 변수를 반복문 내부에서 작성하는 것이 좋다 나쁜 예) var user: User for(i in users.indices){ user = users[i] p.. 공감수 0 댓글수 0 2023. 7. 11.
[이펙티브 코틀린] 코틀린의 안정성 - 가변성을 제한하라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 가변성을 제한하라 사람들이 많이 사용하는 앱이더라도 가끔 생각대로 동작하지 않거나 크래시가 발생하는 경우가 있습니다 이때 사용자들은 앱에 대한 신뢰도가 크게 떨어지게 됩니다 그래서 프로그래밍에 있어서 안정성은 정말 중요한 요소입니다 안정성으로 인해서 좋은 서비스, 나쁜 서비스로 나뉠 수 도 있다고 생각합니다 코틀린은 다양한 개발자들의 경험을 토대로 만들어진 언어이기때문에 사용자들의 신.. 공감수 0 댓글수 0 2023. 7. 9.
[이펙티브 코틀린] 코틀린의 안정성 - 예외를 활용해 코드에 제한을 걸어라 안드로이드는 자바와 코틀린 2가지 언어로 개발을 할 수 있지만 요즘 자바를 사용해서 개발하는 경우는 찾아보기 힘듬니다 저또한 코틀린을 사용합니다 하지만 사용하면서 잘 몰랐던 부분도 있고 한번도 써보지않는 편리고 좋은 기능들이 많이 존재합니다 그래서 이번에 복습할겸 이펙티브 코틀린의 내용으로 정리를 하려고 합니다. 안정성 - 예외를 활용해 코드에 제한을 걸어라 확실하게 어떠한 형태로 동작해야 하는 코드가 있다면, 예외를 활용해 제한을 걸어주는 것이 좋다 코틀린에서 코드 동작에 제한을 거는 여러가지 방법 require 블록 : 아규먼트를 제한 할 수 있다 check 블록 : 상태와 관련된 동작을 제한할 수 있다 assert 블록 : 어떤 것이 true인지 확인 할 수 있다. assert 블록은 테스트모드에서.. 공감수 0 댓글수 0 2023. 7. 8.
[Kotlin] Assignment (=) , get() 의 차이 평소에 잘 생각안하고 많이 사용하는 =, get()의 차이는 무엇 일까요 ? 먼저 코드로 알아보도록 하겠습니다! class Customer { private var _id = 1 // get() 을 사용 val id: Int get() = _id // = 을 사용 val id: Int = _id } 블로그나 깃허브를 돌아다니다 보면 위와 같이 2가지 방법중 하나를 사용해서 가변성을 제안하는 코드가 있습니다 어떤 차이가 있을까요??? 자바 코드로 변경해보면 답이 알 수 있습니다. 먼저 get() 을 사용한 코드를 자바로 변경하면 public final class Customer { private int _id = 1; public final int getId() { return this._id; } .. 공감수 2 댓글수 0 2023. 7. 8.
트라이(Trie) 란? 트라이(Trie)는 문자열의 집합을 표현하는 '트리 자료구조'이다. 원하는 원소를 찾기 위해 자주 이용되는 이진 검색 트리 (STL set, map) 등에서는 원소를 찾는데 **O(logN)**의 시간이 걸리게 된다. 하지만, 문자열의 경우 두 문자열을 비교하기 위해서는 문자열의 길이만큼의 시간이 걸리기 때문에 원하는 문자열을 찾기 위해서는 O(MlogN)의 시간이 걸리게 된다. 따라서 여러 번 이 작업을 수행한다면 시간이 오래 걸릴 것이다. 이 단점을 해결하기 위한 문자열 특화 자료구조가 트라이(Trie)이다. 쉽게 말해, "문자열을 빠르게 탐색할 수 있는 자료구조"이다. 트라이(Trie) 자료구조의 장/단점 트라이의 장점은 앞에서도 언급했듯이 당연히 문자열을 빠르게 찾을 수 있다는 점이다. 더불어, .. 공감수 0 댓글수 0 2023. 5. 15.
맵(Map) 이란? Map은 Key와 Value 한쌍으로 이루어진 자료형이다. Map은 리스트나 배열처럼 순차적으로 해당 요소 값을 구하지 않고 Key를 통해 Value를 얻는다. 값(Value)은 중복될 수 있지만, **Key는 고유한 값(Unique)**을 가져야 한다. Map은 저장 순서를 유지할 필요가 없고, Key를 통해 Value를 얻어내기 때문에 Key는 중복을 허용하지 않는다. 구조도 HashMap, HashTable 키와 값(key, value)이 하나의 쌍을 이루는 데이터 구조이다. 즉, 키와 배열의 인덱스를 이용하여 키를 저장하는 자료구조이다. HashTable은 키를 해시함수(Hash Function)로 계산하여 그 값을 배열의 인덱스로 사용한다. 이때, 해시 함수에 의해 반환된 데이터의 고유 숫자값을.. 공감수 0 댓글수 0 2023. 5. 15.
자료구조의 주요 사용처 배열 (Array) 장점 바로 만들어서 활용하기가 쉽다 더 복잡한 자료 구조의 기초가 될 수 있다 원하는 데이터를 효율적으로 탐색/가져올 수 있다 정렬에 용이하다 단점 데이터를 저장 할 수 있는 메모리 크기가 고정되어 있다 데이터 추가 / 삭제 방법이 비효율적이다 구조 재구성 시 정렬하는 방식이 비효율적이다 사용 엑셀의 스프레드시트 처럼 직사각형 테이블, 수학적 벡터 (vector) 및 행렬 (matrix)를 구현하는 데 사용된다 다른 데이터 구조에서 사용된다 스택 (Stack) 장점 동적인 메모리 크기 데이터를 받는 순서대로 정렬된다 빠른 런타임 (runtime) 단점 가장 최신 요소만 가져온다 한번에 하나의 데이터만 처리 가능하다 사용 가장 마지막으로 입력된 것을 순차적으로 바로 처리하고 싶을 때 브.. 공감수 0 댓글수 0 2023. 5. 15.
셋(Set) 이란? array나 list 처럼 순열 자료구조 (collection) 이지만 set은 순서라는 개념이 존재하지 않는다. Set은 집합이라는 의미를 가진다. Set의 특징 데이터를 비순차적(unordered)으로 저장할 수 있는 순열 자료구조 (collection). 집합의 개념과 같다고 생각하면 된다.(집합 역시 {1, 9, 6, 4}처럼 중복과 순서가 없다.) 삽입(insertion) 순서대로 저장되지 않는다. 즉 특정한 순서를 기대할 수 없는 자료구조. 수정 가능하다(mutable). 동일한 값을 여러번 삽입 불가능하다. 동일한 값이 여러번 삽입 되면 하나의 값만 저장된다. Fast Lookup이 필요할때 주로 쓰인다. Set이라는 인터페이스를 통해 자바에서는 3가지의 Set이 있다. Hash 알고리즘을 .. 공감수 1 댓글수 0 2023. 5. 15.
리스트(List) 란? 자료구조의 인터페이스 Iterable 함수 hasNext List 란 ArrayList, LinkedList 의 구현체이다. 물론 Vector, Stack은 지금은 사용하지않고 호환성을 위해 남아있는 Class 이다. 리스트는 순서가 있는 엘리먼트의 모임으로 배열과는 다르게 빈 엘리먼트는 절대 허용하지 않는다. 리스트는 배열이 가지고 있는 인덱스라는 장점을 버리고 대신 빈틈없는 데이터의 적재 라는 장점을 취함 리스트에서 인덱스는 몇 번째 데이터인가 정도(순서)의 의미를 가진다. (배열-Array에서의 인덱스는 값에 대한 유일무이한 식별자) 빈 엘리먼트는 허용하지 않는다. => java에서는 허용하는 경우가 있음 순차성을 보장하지 못하기 때문에 spacial locality 보장이 되지 않아서 cash h.. 공감수 0 댓글수 0 2023. 5. 15.
배열(Array) 란? 배열은 메모리 상에 데이터(원소)를 연속하게 배치한 자료구조 배열은 같은 타입의 데이터를 여러개 나열한 선형 자료구조 배열은 선언할 때 크기를 정하면, 그 크기로 고정이 된다. 선언된 값은 다시 배열을 선언하지 않으면 변경할 수 없다. 배열의 주소를 살펴보면, 한 칸마다 배열의 자료형의 크기를 가지고 있따. 배열의 자료형이 int라면, 배열 한 칸의 크기는 int(4byte)가 되는 것이다. 배열은 인덱스를 통해서 배열에 있는 요소에 접근할 수 있다. 배열의 특징 추가적으로 소모되는 메모리 양(=overhead)가 거의 없다 Cache hit rate가 높다. cache hit ratio: 적중률 = (캐시히트 횟수)/(전체 참조횟수) cache hit: 참조하려는 데이터가 캐시에 존재할 떄 캐시 히트 .. 공감수 0 댓글수 0 2023. 5. 15.
목의 가치를 극대화 하는 것 비관리 의존성에만 목을 사용 시스템의 끝에서 비관리 의존성과 상호 작용을 검증 목을 스파이로 대체하라(스파이: 직접 작성한 목) 시스템 끝에 있는 클래스의 경우 스파이가 목보다 낫다 통합테스트에서만 목을 사용, 단위테스트에서는 사용x 목은 통합테스트를 위한 것(비즈니스 로직과 오케스트레이션의 분리) 도메인 모델에 대한 테스트는 단위테스트 범주, 컨트롤러 테스트는 통합테스트 통합테스트에서 컨트롤러를 테스트 할때만 목을 적용 테스트당 목이 하나일 필요x 항상 목의 호출 수 확인하기 예상하지 못한 호출 확인 혼자 단위테스트라는 책을 읽으면서 생각에 흐름대로 적은 글입니다. 기록용입니다! 참고한 책은 단위 테스트라는 책입니다. ( http://www.yes24.com/Product/Goods/104084175 ) 공감수 1 댓글수 0 2022. 4. 30.
통합테스트의 역할, 적용 시점, 다른 기법과의 의존 통합테스트란? 단위테스트의 3가지 요구사항 단일 동작단위 검증 빠르게 수행 다른 테스트와 별도로 처리 → 이 세가지 중에 하나도 충족을 못할 시 통합테스트(단위테스트가 아닌 모든테스트가 통합테스트) 단위테스트와 통합테스트 단위테스트와 통합테스트간에 균형을 유지하는 것이 중요 단위테스트로 가능한 한 많이 비즈니스 시나리오의 예외 상황을 확인하고 통합테스트는 주요 흐름과 단위테스트가 다루지 못하는 기타 예외사항을 다뤄야한다.(모든 프로세스의 외부의존성을 거치는 것) 빠른 실패원칙 : 예기치 않은 오류가 발생하자마자 현재 연산을 중단 프로세스 외부 의존성의 2가지 유형 관리의존성 : 애플리케이션을 통해서만 접근가능 ex) 데이터베이스 등 비관리 의존성 : 외부에서 상호작용을 볼 수 있음 ex) SMTP, 메세.. 공감수 0 댓글수 1 2022. 4. 28.
가치있는 테스트를 작성하는 방법 코드의 4가지 유형(복잡도 또는 도메인 유의성 과 협력자 수를 이용해서 분류) 도메인 모델과 알고리즘 : 복잡도 및 도메인 유의성(상) 협력자수(하) 테스트하는 것이 가장 이로움 간단한 코드 : 복잡도 및 도메인 유의성(하) 협력자수(하) 테스트할 필요x 컨트롤러 : 복잡도 및 도메인 유의성(하) 협력자수(상) 간단한 테스트 필요 지나 치게 복잡한 코드 : 복잡도 및 도메인 유의성(상) 협력자수(상) 두부분으로 나누어야한다.(복잡도 및 도메인, 컨트롤러) → 가장 중요 코드가 더 중요해거나 복잡해질수록 협력자는 더 적어야 한다 좋지 않은 테스트를 작성하는 것보다는 테스트를 전혀 작성하지 않는 편이 낫다 험블 객체 패턴 테스트가 가능한 부분을 추출 (험블래퍼) 단일 책임원칙을 지키자 가치있는 테스트를 위한.. 공감수 0 댓글수 0 2022. 4. 26.
출력기반, 상태기반, 통신기반의 테스트 스타일 하나의 테스트에서 3가지 스타일을 모두 사용이 가능 출력기반의 테스트 정의(가장 선호해야한다.) 입력을 넣고 출력을 검증하는 방식 전역상태나 내부 상태를 변경하지 않는 코드에만 적용되므로 반환 값만 검증하면 됨 함수형 프로그램에 뿌리를 두고있음(함수형으로 작성된 코드에만 적용가능) 테스트 대상 메서드에만 결합되므로 거짓 양성방지가 가장 우수(리팩터링 내성 가장우수) 유지비 가장 낮음 상태 기반 스타일 정의 작업이 완료된 후 시스템 상태를 확인하는 것(상태는 SUT, 협력자중 하나) 통신 기반 스타일 정의 목을 사용해서 테스트 대상 시스템과 협력자 간의 통신을 검증 유지비 가장 높음 고전파는 통신기반 스타일보다는 상태기반 런던파는 이와 반대 하지만 두분파는 출력 기반 테스트를 사용 함수형 아키텍처 vs 숨.. 공감수 0 댓글수 0 2022. 4. 25.
목은 훌륭한 도구? vs 사용하면 안 되는 것? 목(Mock) 테스트 대상 시스템과 그 협력자 사이의 상호 작용을 검사하는 테스트 대역 테스트대역: 모든 유형의 비운영용 가짜 의존성을 설명하는 포괄적인 용어 테스트 대역 목(목, 스파이) : 외부로 나가는 상호작용을 모방하고 검사하는 데 도움 목 : 프레임워크의 도움을 받아 생성(가끔 직접 작성) 스파이 : 수동으로 작성 스텁(스텁, 더미, 페이크) : 내부로 들어오는 상호 작용을 모방하는 데 도움 더미 : 단순하고 하드코딩 된 값 스텁 : 시나리오마다 다른 값을 반환하게끔 구성할 수 있도록 해주는 완전한 의존성 페이크 : 대다수 목적에 부합하는 스텁(아직 존재하지 않는 의존성을 대체) 목과 스텁의 차이 목은 SUT와 관련 의존성을 간의 상호작용을 모방하고 검사하지만 스텁은 모방만 한다 목은 명령이고 .. 공감수 0 댓글수 0 2022. 4. 24.
좋은 단위 테스트의 4대요소(회귀방지, 리팩터링 내성, 빠른 피드백, 유지보수성) 회귀방지 회귀는 소프트웨어 버그이다(기능이 의도한대로 동작x) 단순한 코드를 테스트하는 것은 가치가 거의 없다 회귀 방지 지표를 극대화 하려면 테스트가 가능한 한 많은 코드를 실행하는 것을 목표로 해야한다. 리팩터링 내성 테스트에서 얼마나 많이 거짓양성이 발생하는지 살펴봐야하한다(적을 수록 좋음)(거짓음성: 테스트는 잘 동작하지만 기능은 실패) (거짓양성: 기능은 잘 동작하지만 테스트는 실패) 테스트를 실패로 변경하지않고 코드를 리팩터링 할 수 있는지에 대한 척도이다.SUT의 구현 세부 사항과 테스트간의 결합도를 낮추는 것뿐이다 즉, 코드의 내부 작업과 테스트 사이를 가능 한 멀리 떨어뜨리고 최종결과를 목표로 하는 것. → 테스트를 깨지지않게 하고 리팩터링 내성을 높이는 방법 회귀방지와 리팩터링 내성의 .. 공감수 0 댓글수 0 2022. 4. 23.
단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 안녕하세요~ 헬창코딩 입니다. 참고한 책은 블라디미르 코리코프님이 지으신 UnitTesting란 책입니다. 오늘은 책의 3장의 내용을 정리하고 복습하려고 합니다. 주제 (arrange, act, assert) AAA 패턴의 단위 테스트의 구조에 관한 설명 단위 테스트를 가능한 한 읽기 쉽게 만드는 방법 AAA 패턴 각 테스트를 준비, 실행, 검증 3가지로 단계로 나눌 수 있다. 모든 테스트가 단순하고 균일한 구조를 갖는 데 도움이 된다(일관성이 가장 큰 장점) AAA 패턴의 단계 준비 구절 테스트의 대상 시스템과 해당 의존성을 원하는 상태로 만든다. 실행 구절 테스트 대상 시스템에서 메서드를 호출하고 준비된 의존성을 전달하고 출력값을 캡처한다. 검증 구절 결과를 검증한다. (결과는 반환 값이나 테스트 대.. 공감수 1 댓글수 1 2022. 3. 6.
Delegate Pattern - kotlin (by를 사용해서 쉽게) 안녕하세요 헬창코딩입니다. 오늘은 delegate pattern에 대해서 알아보도록 하겠습니다 델리게이트 패턴은 어떤 기능을 자기 자신이 처리하는 것이 아니라 다른 객체에 delegate(위임) 시켜서 그 객체가 일을 처리하도록 하는 패턴이 바로 delegate pattern입니다. delegate pattern을 사용하는 이유가 무엇일까요?? delegate pattern의 필요성을 설명하기 전에 먼저 상속과 구성에 대한 내용을 이해해야 합니다. 흔하게 상속은 is - a의 관계라고 말하죠 예를 들어 동물이라는 클래스가 강아지라는 클래스의 부모 클래스라면 강아지 is 동물 관계가 성립을 하는 것이죠 이런 경우에는 클래스의 변수와 메서드를 상속받아서 새로 구현을 해줄 필요가 없습니다. 하지만 이러한 상속.. 공감수 4 댓글수 1 2022. 3. 5.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.