Fact
- 아침에 java로 JadenCase를 풀고 JavaScript로 N개의 최소공배수를 풀었다.
- 둘다 쉬워 보이는 문제라 README를 작성 안했다. JadenCase는 문자열에 있는 단어들의 첫번째 글자를 대문자하고 그후의 글자는 소문자로 변환하는 거였다. 그래서 java stream 연습할겸 java로 풀었다.
- 두번째 문제는 javaScript를 써서 풀었는데 사실 그냥 프로그래머스 웹 사이트 안에 있는 코드 블럭에서 작성하고 제출을 했다. 이정도면 효율성 문제겠지 하면서 제출 했는데 황당하게도 효율성 문제도 아니고 심지어 통과가 됬었다.
- 오늘 lotto tickets를 계속 짰다. 짜면서 DTO도 적용을 해봤다. 그러나 제대로된 tdd방식으로 짠게 아니라 다음에 다시 처음부터 짜도록 하자.
Feelings
- tdd 참 어렵네요.
Findings
private 메서드들을 태스트 해야하나 말아야하나
(아래는 다른 사이트에서 따온 글)
-
private method tests
- Don’t test private methods.
- Give the methods package access.
- Use a nested test class.
- Use reflection.
Generally a unit test is intended to exercise the public interface of a class or unit. Therefore, private methods are implementation detail that you would not expect to test explicitly.
Unit testing is not a replacement for source code metrics, static code analysis tools and code reviews. If private methods are so complex that they need separates tests then it probably needs to be refactored, not more tests thrown at it.
it basically means that you can test the functionality of the private methods using the public method that invokes them.
요약하자면 private method를 꼭 테스트를 해야 할 정도로 복잡성을 가지고 있다면 그 코드는 망 스멜 나는 코드이므로 빨리 리팩토링 하도록. 그게 아니면 그 private method를 쓰는 public method를 통해서 테스트를 돌려라.
reflection 이용 예제(private의 권한 열어서 테스트 하기)
public class lottoNumber {
...
private static boolean validate(int num) {
if (num > 45) {
return false;
}
return true;
}
...
}
public void validateTest() throws Exception {
Method checkValue = lottoNumber.class.getDeclaredMethod("validate", int.class);
checkValue.setAccessible(true);
boolean result = (boolean)checkValue.invoke(checkValue, 46);
assertFalse(result);UI로 쓰기 위해서, DB에 저장, 요청 응답할 때 쉽게 줄 수 있게끔 데이터를 임시로 저장하는 곳이라는 것 같다(이해를 잘 못해서 아닐 수도 있다).“DTOs are called data transfer objects because they are intended to transmit data from expensive remote calls.”라고 마틴 파울러가 지칭한다. 그러니깐 DTO는 계층 간에 데이터를 교환하기 위한 객체이다. 또한 데이터를 한 번에 묶어서 보냄으로써 수많은 교환을 방지할 수도 있다.
DTO를 작성하게 되면 보통 수많은 변수들과 그것들을 가져오거나 수정할 수 있는 getter와 setter 메서드들로 이루어져 있다.
tdd 방식으로 코드를 할 때는 당장 필요한 것만 작성을 해서 그때그때 필요한 것을 추가 해나가는 방식이다. test가 중요한 게 아니라 이 tdd 사고방식이 핵심이다. 우리가 예측해서 짜는 게 결국에 꼭 필요한 게 아닐 수도 있고 혹은 필요한 거랑 살짝 다른 거일 수도 있으니 당장 필요한 것을 tdd 방식으로 짜면서 나아 가는 게 더욱 정확하고 시간 낭비가 줄어든다. 만드는 것의 핵심부터 짜고 꼭 필요한 게 아니면 하드 코딩을 해서라도 완성하자. 그 후에 하나씩 하드 코딩 한 것들을 바꿔 가면서 완성해나가면 된다. class의 test를 짤 때 이 class의 핵심 기능들이 잘 작동하는지 테스트를 하고, assertThat(assertTrue, assertEquals보단 저게 문맥상 낫다)와 에러 처리하는 것으로(assertThatThrownBy, assertThatIllegalArgumentException 등) 적절히 설명하는 게 좋다.
Future Action
- 오늘 로또게임을 java로 계속 짜긴 했는데 tdd로 짠 게 아니라 다시 처음부터 짜봐야겠다. tdd 사고방식을 키우면서 더 나은 코드를 짤 수 있도록 열심히 tdd 사고방식을 연마하자.