Facts
•
블랙박스 테스트의 기법 리마인드
•
클린코드 5챕터 형식 맞추기 공부
•
코드숨 스프링 3기 3주차 미션 Spring Web으로 만드는 ToDo REST API 미션 진행
◦
미션 피드백 정리 및 학습
Feelings
코드숨 3주차 미션 진행
3주차 미션을 시작하며 본격적으로 테스팅을 실제로 하나씩 해보았다.
나름 TDD과정, ATDD과정도 다 수료했었고 종립님의 BDD도 해보면서 연습을 한 적도 있었기에 어느정도 자신은 있었다. 하지만, 아직도 내게 많은 부족함을 매일매일 리뷰를 통해 알 수 있었고, 실제 프로덕션 코드를 작성할 때 보다 테스트 코드를 작성할 때 변수명과 테스트가 의도를 명확하게 드러내지 못했을 때 테스트의 의미가 퇴색되는게 많이 느껴졌다.
그리고 리뷰를 진행하며 내가 공부를 했던 부분들에 대하여 리마인드 하는 계기이기도 했는데, 다시 한 번 내가 새로운 지식을 배우는것도 중요하지만, 지금까지 공부한 내용들을 다시 한 번 리마인드 해야 할 중요성을 깨달을 수 있었다.
이건 내가 가진 큰 걱정이기도 하다. 이번 미션 진행중에도 나온 키워드인 진리표, 코드의 나열에 있어서 우선순위를 가지거나 어떻게 정렬을 시킬지에 대해서 얘기가 나왔는데, 여기서 진리표는 블랙박스 테스트에 대해 포스팅을 할 때 기법들 중 하나인 의사결정 테이블 테스팅 이라는 기법으로 정리를 했던 적이 있다.
그리고, 코드의 정렬에 있어서도 클린코드의 5챕터 형식 맞추기를 공부하면서 포스팅을 했었다.
그래서 리뷰에 해당 내용이 나왔을 때 어 이거? 하면서 키워드는 떠올르지만 이에 대해 설명은 할 수 없어서 블로그를 뒤져봐야했는데, 만약 기술면접을 본다고 할 때 블로그 찬스 쓸 수 있을까요?!
한 다음에 블로그를 볼 수는 없으니 누르면 나올 수 있게 체득해야 하는데 그러지 못해 문제다.
나름 암기를 해두어도 시간이지나며 또 까먹으니 또다시 공부를 해야겠다.
블랙박스 테스팅 기법
도메인 테스트를 리뷰하시면서 진리표가 생각나셔서 언급을 해주셨다.
처음엔 아 그러네 근데 진리표가 뭐였지~ 하다가 검색해보고 아 이거구나 하고 넘기려는 찰나 갑자기 든 생각이
내가 이걸 포스팅한적이 있는 것 같은데...?
그래서 테스트 관련 카테고리 포스팅한거를 뒤적거리다보니 나온게 이 글이다.
나는 이전에 이미 이 기법에 대해서 학습을 했었는데, 체득하지 못해 기억조차 못하고 있었다.. 반성하자!
클린코드 5챕터 형식 맞추기 공부
사실 코드 컨벤션 부터 api의 http method별 반환 포맷같은건 회사마다 다 상이할 수 있기에 정답은 없다. 그래도 고민은 해보면 좋을 내용으로 코드의 정렬을 할 때 나열을 하느냐이다.
어떻게 나열을 하든간에 코드는 돌아간다. 하지만, 클린코드라는 책을 관통하는 주제이며 많은 개발자들이 고민하는 부분이 바로 의사소통에 용이하고 유지보수가 쉬운 코드를 짜는 것인데, 그래서 코드를 작성할 때 변수나 메서드명을 명시적으로 축약어를 최소화하고, 메서드의 로직도 하나의 메서드가 하나의 일만 하도록 순수함을 추구한다.
그렇기에 코드의 변수와 상수 그리고 공개 메서드와 종속 메서드의 나열 역시 어떻게 할 지 고민해볼 문제이다. 이에 대해서는 아래에서 좀 더 자세히 알아보자.
Finding
블랙박스 테스팅 기법 - 의사결정 테이블 테스팅
Task 도메인 유닛 테스트에서 논리적 동치관계 비교 테스트에서 나왔던 리뷰 내용이다. 테스트를 하다보니 하나하나의 상황에 따른 결과가 나열되는데 이게 진리표와 같다는 말이 나왔는데, 이는 테스팅 기법중 의사결정 테이블 테스팅 기법을 떠올리게 한다. 이 기법에 대해 알아보기 전에 우선 블랙 박스 테스트(Black Box Test)에 대해 이해를 해야하는데, 블랙박스 테스트란 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법으로 관점을 이 소프트웨어가 무슨 역할을 수행해야하는가? 라는 결과에 집중하는 것이다. 그렇기에 내부에서 사용된 상세 기술들에 대한 이해는 필요치 않다. 즉, 개발자 입장이라기보다는 소프트웨어 혹은 제품에 대한 요구사항과 결과물이 일치하는지 검사하는 사용자 입장에서의 테스트 기법이다. 이는 여러가지 기법이 있지만, 이는 위에 올린 링크에 작성되어 있고 여기에선 간단하게 의사결정 테이블 테스팅에 대해서만 얘기하자면 이는
의사결정 테이블 테스팅이란?
논리적 조건이나 상황에서 입력 조건과 결과를 참, 거짓으로 표현해 조합을 만들고 테스트를 작성한다. 가령 예를들어 광고 회사에서 화장품을 홍보하기위해 적절한 홍보 타겟을 결정하기 위해 의사 결정표를 만들고 중복되는 내용을 통합하여 해당 표를 가지고 테스트 케이스를 작성한다.
Plain Text
복사
예전 회사에서 진행했던 프로젝트에서 화장품 추천 솔루션을 진행했던 적이 있는데 거기서 고객층에 대한 테이블을 작성하여 비슷하게 테스팅을 진행했던 경험이 있어 이에 비유를 했다.
클린코드 5챕터 - 형식 맞추기
이 내용은 위 리뷰를 받아보면서 떠올리고 리마인드 하여 공부했던 주제이다.
하나의 소스파일에는 상수, 정적변수, 멤버변수, 지역변수, public 메서드, private메서드 기타 등등 많은 종류가 있다. 클린 코드라는 책에서는 좋은 코드란 신문처럼 혹은 책처럼 위에서부터 줄줄 잘 읽기는 소설과 같은 코드가 좋은 코드라는 내용이 있었던 기억이 있다.
그럼, 술술 읽히도록 코드를 작성하기위해서는 여러 고민점이 있겠지만, 이 중 위에서부터라는 주제로 한정지어서 세로 밀집도나 수직거리에 대해 생각해보면 좀 더 고민하기 쉬워진다.
두가지의 큰 주제와 그를 좀 더 상세히 나눈 소주제로 분류하면 세로 밀집도 수직거리를 다음과 같이 정리할 수 있다.
수직 거리와 세로 밀집도
•
신문 기사처럼 작성하라
◦
위에서 아래로 내려가면서 읽을 수 있도록 작성하자.
◦
첫 문단에 전체 기사 내용을 요약하자. (API 메서드를 최상단에 위치하자.)
◦
내려가면서 세세한 세부사항을 보여주자.
•
개념은 빈 행으로 분리하라.
◦
일련의 행 묶음을 완결된 하나의 생각으로 표현하자.
//worst case
package catsbi.me.widgets;
import java.util.regex.*;
public class BoldWidget extends ParentWidget{
public static final String REGEXP = "'''.+?'''";
private static final Pattern pattern = Pattern.compile(""'(.+?)""',
Pattern.MULTILINE + Pattern.DOTALL);
public BoldWidget(ParentWidget parent, String text) throws Exception{
super(parent) ;
Matcher match = pattern.matcher(text);
match.find ( ) ;
addChildWidgets(match.group(l));}
}
public String render() throws Exception {
...
}
}
//good case
package catsbi.me.widgets;
import java.util.regex.*;
public class BoldWidget extends ParentWidget{
public static final String REGEXP = "'''.+?'''";
public BoldWidget(ParentWidget parent, String text) throws Exception{
...
}
public String render() throws Exception {
...
}
}
Java
복사
•
서로 밀접한 개념을 세로로 가까히 둬서 코드를 트레이싱할 때 코드를 위 아래로 중구난방 돌아다니지 않게 하자.
→ 변수는 사용하는 위치에 최대한 가까히 선언하자.
→ 인스턴스 변수는 클래스 최상단에 선언하자. 변수간의 세로로 거리를 두지 말자.
→ 종속함수는 세로로 가까히 배치하자. 그리고 가능한 호출하는 함수를 먼저 배치하자.
→ 개념적으로 친화도가 유사한 의미의 함수를 가까히 두자.
(Ex: 객체의 getter/setter and constructor)
Affirmation
놀지는 않고, 퇴근 후, 주말에 공부를 쉬지 않았기에 적어도 주제에 대한 키워드들은 꽤나 많이 떠오른다. 그동한 작성했던 포스팅도 꽤 양이 쌓이니 내가 내 글을 보고 리마인드하기도 쉬워진다.
하지만, 글을 보지 않고 리마인드 할 기억력이 안된다는건 단순히 머리가 나쁘다 라고 핑계를 대는건 뭔가 얍삽하다.
그냥 내가 더 꼼꼼히 꾸준히 리마인드 하지 않았기에, 그리고 해당 학습내용을 충분히 연습하지 않았기에 죽어버린 지식이 휘발된것에 불과하다.
이전에 티비에서 모범생, 우수생들의 노하우로 나왔던 것 중 하나가 다회독이였다.
옛날에 과거시험을 보던 선비들도 하나의 책을 수백 수천번씩 다회독을 하면서도 시험에 떨어지곤 한다. 그런데 나는 기껏해야 1회독도 겨우하고 2회독하고나선 다시는 들춰보지도 않는데, 당연한 결과인 것 같다.
내가 모르는게 너무 많아서 조급할 수 있고, 시니어 개발자분들의 리뷰를 받으면서 감탄과 동시에 나는 너무 모르는게 많다는 답답한이 조급함이 되어 새로운 지식이나 분야만 공부를 하려 했는데, 잠시 내려놓고 배운 지식들을 잘 정리하는게 우선일 것 같다.
