오천~금강 자전거 종주길을 다녀왔다. 이번 자전거 종주를 시작으로 그랜드 슬램 달성을 위해 지금까지 가지 못한 모든 종주길을 올해안에 완수하는게 목표였다.

총 1박2일 코스로 다녀왔는데 첫날 6시 30분에 동서울 터미널을 출발해서 다음날 21시 10분에 동서울 터미널을 도착하는것을 끝으로 이번 오천~금강 자전거 종주를 끝마쳤다. 남들은 2박 3일을 코스로 널널하게 잡고 간다고 하는데 조금만 열심히 달리면 1박 2일 코스로 충분히 갈 수 있을 것 같기도 하였고 무엇보다 불필요하게 숙박을 하면서 숙박비를 쓰고 싶지는 않았다.

출발할때 버스시간과 출발지가 애매한 곳에 있어서 어쩔 수 없이 이화령 고개를 넘어야 했는데 시작부터 힘을 빼고 시작하다보니 첫날 밤 숙소에 도착했을 때에는 녹초가 되었었다. 코스 이름에서 유추할 수 있듯이 오천~금강 코스는 다섯개의 천과 금강을 따라 가는 코스이다. 그러다보니 대부분 천이나 강둑으로 난 코스를 달리게 되는데 그늘도 거의 없고 주변에 구경거리도 많이 없어서 혼자 달리기에는 조금 지루한 코스가 많았다.


9월 말에는 동해안 종주길을 다녀왔다. 지금와서 하는 이야기이지만 지금까지 다녔던 국토종주 중에 가장 힘든 코스가 바로 동해안 종주길이었다. 강원구간은 그렇게 힘들진 않았는데 경북구간은 낙타등 코스가 너무 많아서 마지막에는 다리에 쥐가 나서 제대로 달리지도 못했던 것 같다. 거기다 첫날은 역풍에 비까지와서 정말 힘들게 달렸다.

그래도 동해안 풍경이 좋기도 하였고 가는길 중간에 서핑중인 회사사람들도 만나서 맛있는 것도 먹고 재미는 있었다. 만약 다시 종주길을 간다면 동해안 종주길 강원 구간은 다시 또 가고 싶긴하다.


최근들어 많이 느끼는 건데 우리팀이 프로젝트를 진행하면서 작고 꼭 필요한 기능만 우선적으로 출시한 다음 피드백을 받고 점점 발전 시켜가는 방식으로 개발하는 것에 익숙하지 않다라는 느낌을 많이든다. 기획 논의를 하다보면 제품의 사양이 점점 커져가고 반드시 고민하지 않아도될 사양까지 고민하면서 요구사항이 점점 복잡해지고 프로젝트 크기가 점점 커지는 경우가 많아지고 있다.

예전에는 형식적으로나마 스크럼방식으로 개발프로세스를 진행하면서 나름 기능을 요구사항을 최소화하는 모양새였는데 요즘에는 그마저도 하지 않으면서 지금 우리 팀은 사람에게 의존하는 참 비효율적인 개발 프로세스를 진행하고 있는 상태이다. 현재 구성원들이 대부분 입사한지 1년이 지난 분들이고 어느정도 업무에 적응했다보니 형식적인 것들보다는 그냥 그때그때 편한대로 업무하는게 좀더 편하다고 생각하는 것 같다. 관리자도 아니다보니 개선사항을 강하게 이야기할 수도 없고….좀 더 지켜봐야겠다.


아래는 9월동안 정리한 이슈 내용들이다.

SQL 테스트 설계에 대한 다섯가지 지침

이펙티브 소프트웨어 테스팅에서 알려주는 SQL 쿼리에 대한 테스트를 설계할 때 참고할만한 다섯가지 지침이 있는데 참고하면 좋을 것 같아 적어본다.

SQL 조건문을 위한 수정된 조건/의사결정 커버리지(MC/DC) 적용

SQL문에는 의사결정이 일어나느 곳이 세군데가 있는데 join, where, having 조건이다. 이러한 조건에 MC/DC를 적용하자

널 처리를 위한 MC/DC 적용

true, false, null로 된 조건을 제공해야한다.

선택한 데이터에 대한 범주-구획 처리

행을 검색하는 경우

쿼리가 어떤 행도 검색하지 못하도록하는 테스트를 포함한다.

행을 병합하는 경우

쿼리 결과에 의도치 않는 중복행이 나타나는지 확인해야한다.

행을 그룹화 하는 경우

group by 절에 적어도 두개의 서로 다른 그룹을 얻도록 설계해야한다. 그룹화에 사용된 값은 같고 그 외의 것은 다르게 해야한다.

행을 서브쿼리로 검색하는 경우

각각의 서브쿼리에 대해 0개 이상의 행을 반환하는 테스트 상태를 포함한다. 선택된 열에 대해 적어도 하나의 null과 두개의 서로다른 값이 있어야 한다.

값이 집계 함수에 참여하는 경우

각가의 집계함수에 대해 함수가 두개의 같은 값과 하나의 다른 값을 가지도록 하는 테스트 상태를 하나이상 포함한다.

그 외의 표현식

범주 구획 검사 및 경계검사를 이용하여 like 술어, 날짜 관리, 문자열 관리, 데이터 타입 변환 또는 기타 함수를 포함하는 표현식에 대한 테스트 상태를 설계한다.

출력값 검사

특정 컬럼 값이 null이나 빈값을 반환하는지 확인하는 검사를 포함한다.

데이터베이스 제약사항 검사

데이터베이스의 제약사항을 확인하고 검사한다.

Kotlin equals함수의 ignorecase매개변수

문자열에 대한 동등성을 확인할 때 equals를 흔히 사용한다. 특히 Kotlin에서는 == 연산자로도 equals와 같은 동작을 수행하는데 만약 대소문자를 구분하지 않고 동등성을 확인할 때에는 자바방식으로는 아래와 같이 했었다.

"example".lowercase() == "EXAMPLE".lowercase()

하지만 Kotlin에서 equals함수에 ignorecase매개변수가 있다는 것을 알게 되었고 앞으로 아래와 같이 작성하게 되었다.

"example".equals("EXAMPLE", ignoreCase = true)

mockk 라이브러리에서 public이 아닌 생성자를 이용하고 싶을 때

mockk 에서 외부 라이브러리를 mocking 할때 public이 아닌 생성자만 제공하는 경우 mockk 또는 spyk를 생성할 수없는 이슈가 있다. 이럴때 아래와 같이 mockkConstructor를 이용하면 mocking 을 할 수 있다.

mockkConstructor(Sheets.Spreadsheets::class)
mockk<Sheets.Spreadsheets>(relaxed = true)

kotlin의 새로운 증분 컴파일 방식

kotlin 1.7부터 컴파일 회피 기능이 적용되었다고 한다. 아직 JVM 백엔드에서만 실험적으로 적용중이라 한다.

https://blog.jetbrains.com/ko/kotlin/2022/08/a-new-approach-to-incremental-compilation-in-kotlin/#how-to