-
AssertJ 오픈소스 컨트리뷰트 하기Spring 2024. 8. 5. 02:37
서론
여러 프로젝트를 진행하면서 테스트코드의 중요성에 대해서 느낄 수 있었다. 소형테스트와 중형테스트 그리고 대형테스트를 엄격하게 분리하여 코드를 작성해보며, 각 단계들의 테스트들이 단계에 맞는 역할을 하도록 만들었다. 이를 통해, 각 단계의 테스트코드들의 가독성을 높일 수 있었고 더하여 소형테스트와 Embedded DB를 분리함으로써 성능또한 높일 수 있었다.
Spring에서는 일반적으로 AssertJ를 이용하여 테스트코드를 작성한다. AssertJ는 테스트코드 작성을 도와주는 Java Libary이다. Spring 개발자로서 본인도 AssertJ를 밥먹듯이 사용하여 테스트코드를 작성하고 있다.
AssertJ를 사용해보며 문득, AssertJ가 어떻게 만들어졌는지에 대해 궁금하여 AssertJ 오픈소스를 찾아보게 되었다. AssertJ의 core 코드들을 확인하고, 열려있는 여러 Issues들을 보면서 나도 AssertJ 오픈소스에 기여할 수 있지 않을까? 라는 생각이 들어 기여할만한 이슈들을 찾아보았다.
본론
깃허브 이슈
StackOverFlow 이슈
깃허브와 스택오버플로를 통해서 위와 같은 이슈를 확인할 수 있었고, 개인적으로 개선이 된다면 테스트코드를 작성할때 많은 개발자들이 편리하게 사용할 수 있을것 같다라고 생각하였다.
<깃허브 이슈 내용>
<스택오버플로 이슈 내용>
문제점
- satisfies(allOf(condition…)) 을 사용하면, 조건이 충족되지 않았을 경우 어떤 조건이 틀렸는지 나오지 않는다
직관적으로도 어떤 문제인지 충분히 이해가 가능하다.
어느 부분을 살피면 될까?
satisfies와 allOf가 동시에 사용되었을때의 경우를 살펴 보아야 한다.
해당 케이스를 보기전에 satisfies와 연관된 다른 케이스들은 어떻게 처리하는지 확인을 해볼수 있다
1. satisfies 와 condition이 같이 사용된 테스트 코드
- 테스트코드가 조금 이상한게, 테스트를 포함하고 있지 않다
2. satisfies를 사용하지않고 allOf를 이용해서 여러 condition을 확인하는 테스트코드
- 해당 코드에서는 conditionDescriptionStatus를 이용하여서 allOf내의 컨티션들을 검증한다
- 해당 함수를 이용하면 어떤 테스트를 통과했는지, 안했는지 확인할 수 있다
즉, conditionDescriptionStatus 를 활용하면 우리가 원하는 결과를 얻을 수 있을 것으로 예상할 수 있다.
그렇다면 ?
이번 PR의 목표도 satisfies(allOf(condition….))을 사용해서
이와 같은 형태를 만드는 것을 목표로 한다
오픈소스 분석하기
상속구조 분석
AllOf는 Join을 상속받고 , Join은 Condition을 상속받는것을 확인할 수 있다.
가장 중요한 conditionDescriptionWithStatus는 어떻게 만들어진걸까?
- 모든 컨티션들을 들어온 값(actual)을 loop을 돌아준다
- 하나라도 틀리면 실패한 것이기 때문에 status(actual).label = [x]로 고정이 된다. 그렇지 않다면 label=[v]
- 테스트의 성공여부들은 descriptionWithStatus에 저장되어, 이후 출력할때 각 테스트마다 label을 달아주도록 할 수 있다
- 결과적으로
- [✗] all of:[ [✓] TestCondition, [✗] TestCondition ] ←- 이런식으로 나온다
다시 돌아와서 satisfies.allOf(condition…)은 어떻게 호출될까?
이미 satisfies가 호출되는 시점에서 고정된 all of :[….] 가 나오는것을 확인할 수 있다
Condition.java
- conditionDescriptionWithStatus을 호출하여, condition에 대한 Descriptioin을 얻을 수 있다
- assertSatisfies에 shoudSatisfyAll를 호출하여 결과값을 반환한다
- shouldSatisfyAll함수는 Description을 인자로 받고, 에러를 던질때 Description을 기반으로 던진다
테스트코드
올바른 경우
틀린경우
결론
satisfiy에 allOf가 있는 경우 어떤 케이스가 틀린 케이스인지 명시하도록 오픈소스를 수정해보았다.
결론적으로 PR이 Merge가 되었고 나도 AssertJ 컨트리뷰터가 될 수 있었다 !!
https://github.com/assertj/assertj/pull/3554
오픈소스라는것이 처음에는 대단한 사람들만 하는 것 같고, 내가 여기 기여할 수 있을까? 라는 생각들을 가질 수 있다. 나도 그랬다. 하지만, AssertJ뿐만 아니라 Spring-data-mongodb, argocd등을 기여해보며 누구나 오픈소스의 컨트리뷰터가 될 수 있고 이러한 컨트리뷰터의 기여를 바탕으로 오픈소스가 발전하고 개발자들이 더 좋은 프레임워크 혹은 라이브러리를 사용할 수 있게 되는것이라고 생각한다.
오픈소스 컨트리뷰트 문화가 좀 더 발전하고자 하는 마음으로 이번 AssertJ 메인테이너분에게 Sponsor도 하였다.
많은 사람들이 오픈소스를 사랑하고 기여하는 문화가 활발해졌으면 좋겠다.
'Spring' 카테고리의 다른 글
지연로딩 , 즉시로딩 JPA 최적화 (1) 2024.07.01 Spring - gRPC 적용 성능 최적화 (0) 2024.05.01 Kafka를 이용한 채팅서버 개발 (0) 2024.03.15 서버 성능개선 - sql batchupdate (0) 2024.01.11