포스트

2021-02-08-TIL

2021-02-08-TIL

디자인 패턴을 배우는 시점

디자인 패턴을 괜히 적용하려다가 코드가 망가지는 경우가 많다. 디자인 패턴은 모든 것을 학습하고 난 후에 학습하는 것이 좋다.

패턴은 반복해서 나타나는 설계 문제에 대한 해법에 이름을 붙인 것이다. 그래서 그 문제를 직접 겪어 보기 전에 해법부터 적용하면, 문제가 없는 곳에 구조만 늘어난다. 패턴을 먼저 고르고 코드를 끼워 맞추기보다, 코드에서 불편한 지점이 보였을 때 그 문제에 맞는 패턴이 있는지 찾는 순서가 자연스럽다.


Git 협업 규칙

브랜치는 머지되고나면 삭제하는 것이 일반적이다.

머지된 브랜치의 커밋은 이미 대상 브랜치의 이력에 들어가 있으므로, 브랜치를 지워도 작업 내용은 사라지지 않는다. 브랜치 목록에 끝난 작업이 쌓이지 않도록 정리하는 것이다. GitHub에는 풀 리퀘스트가 머지되면 head 브랜치를 자동으로 지우는 저장소 설정도 있다.

실제로는 변경사항이 아니라 파일을 통째로 스테이지에 추가한다.

Pro Git은 Git이 데이터를 변경분(diff)이 아니라 스냅샷의 흐름으로 다룬다고 설명한다. 커밋할 때마다 그 순간 모든 파일이 어떤 모습인지 찍어 두고, 바뀌지 않은 파일은 이전에 저장한 것을 가리키기만 한다. 스테이징도 같은 방식이다. git add는 수정한 파일의 “현재 버전”을 다음 커밋 스냅샷에 넣기로 표시한다. 그래서 git add 후에 파일을 또 고치면, 나중에 고친 부분은 다시 add하기 전까지 커밋에 들어가지 않는다. 세 영역(작업 디렉터리, 스테이징 영역, 저장소)은 Git의 기본을 어떻게 이해해야 하는가에 정리했다.

로컬에서는 리베이스를 사용하되, 협업환경에서는 머지를 사용하는 것이 안전하다.

리베이스는 커밋을 새로 만들어 이력을 다시 쓴다. Pro Git의 규칙은 “저장소 밖에 있고 다른 사람이 그 위에 작업했을 수 있는 커밋은 리베이스하지 말라”는 것이다. 이미 공유된 커밋을 리베이스하면 동료들이 자기 작업을 다시 머지해야 한다. 그래서 Pro Git도 푸시하기 전의 로컬 변경은 리베이스로 정리하고, 어딘가에 푸시한 것은 리베이스하지 않는 방식을 권한다.

force push 보다는 git revert로 취소커밋을 하는것이 바람직하다.

git revert는 이전 커밋의 변경을 되돌리는 새 커밋을 기록한다. 이력을 지우지 않고 뒤에 덧붙이므로, 이미 그 커밋을 받아 간 사람들의 저장소와도 충돌하지 않는다. 반면 git reset으로 커밋을 지운 뒤 force push하면 원격 이력이 바뀌어, 다른 사람이 가진 이력과 어긋난다.


Gradle로 테스트를 실행할 때만 나는 에러

image-20210208205132616

여기에서 gradle로 테스트 코드를 실행할때만 아래와 같은 에러가 발생한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources NO-SOURCE
:testClasses UP-TO-DATE
:test
:test FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':test'.
> No tests found for given includes: [net.honux.chess.PawnTest]
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 0.066 secs

따라서, 그냥 JUnit5 아이콘이 있는 맨 아래 모듈로 실행하면 된다.

IntelliJ에는 Gradle 프로젝트의 테스트를 무엇으로 실행할지 고르는 “Run test using” 설정이 있다. Gradle로 실행할 수도, IntelliJ의 JUnit 실행기로 실행할 수도, 테스트마다 고를 수도 있다. 에러 메시지의 No tests found for given includes: [net.honux.chess.PawnTest]는 Gradle이 PawnTest만 골라 실행하라는 필터를 받았지만, 실행할 테스트를 하나도 찾지 못했다는 뜻이다.

JUnit 5로 작성한 테스트라면 Gradle 설정을 먼저 확인해 볼 만하다. Gradle 문서는 JUnit 5를 JUnit Platform, JUnit Jupiter, JUnit Vintage 세 모듈로 설명하고, Gradle에서 JUnit Platform으로 테스트를 실행하려면 test 태스크에 useJUnitPlatform()을 켜고 Jupiter 의존성을 추가하라고 안내한다. 이 설정이 빠져 있으면 IntelliJ의 JUnit 실행기로는 돌아가는 테스트가 Gradle로 실행할 때만 발견되지 않을 수 있다.

1
2
3
4
5
6
7
8
9
// build.gradle
test {
    useJUnitPlatform()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.6.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine'
}
참고한 자료외부 출처 6

외부 출처

이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다