평범한 개발자 얏얏이 평범한 개발자 얏얏이

컨트롤러를 테스트하려고 했는데 어떤 범주까지 해야할지 모르겠어서 해본다. 어느 법주까지 테스트를 하려는지 아려면 컨트롤러의 책임을 먼저 알아야 겠다고 생각했다. Controller Layer - application의 공개적인 facae이다. - 요청이 들어오고, 응답을 반환해주는 루트이다. 테스트... 그럼 요청에 대한 테스트와 응답에 대한 테스트를 해주면 되지 않을까? 1. 요청에 대한 validation? 예를들어 필요한 인자가 오지 않았다던가, 그런 것들... 가장 앞단에서 이런 것들을 처리해 주지 않으면 뒷단에 있는 애들이 번거롭지 않을까? 아래 내용을 보니 request에 대한 테스트를 하고 있다. https://jeong-pro.tistory.com/203 스프링 부트에서 Request 유효..

초록 막대 패턴 가짜로 구현하기 - 첫 번째 구현은 상수를 반환하게 한다. - 단계적으로 상수를 '변수를 사용하는 수식'으로 변형한다. - 가짜 구현은 확신을 가지게 해준다. - 구현 범위를 조절해 준다. 삼각 측량 - 예가 2개 이상일 때만 추상화를 진행한다. 하나에서 여럿으로 - 여럿에 대한 연산은 여럿 없이 구현하고, 그 다음 여럿으로 구현한다.

테스트 주도 개발 패턴 격리된 테스트 - 각각의 테스트는 서로 독립적이어야 한다. - 테스트를 격리하기 위한 작업은 결과적으로 시스템이 응집도는 높고, 결합도는 낮은 객체의 모음으로 구성되도록 한다. 테스트 목록 - 구현해야할 것들에 대한 테스트 목록을 적는다. - 구현할 필요가 있는 모든 오퍼레이션의 사용 예들을 적는다. - 존재하지 않는 오퍼레이션에 대해서는 해당 오퍼레이션의 널 버전을 리스트에 적는다. - 작업을 끝내기 전에 반드시 해야할 리팩토링 목록을 얻는다. - 새로운 테스트 코드와 리팩토링이 발견되면 적어둔다. 테스트 우선 테스트 대상이 되는 코드를 작성하기 직전에 하는 것이 좋다. 단언 우선 가장 먼저 assert를 적고 시작하라. 테스트 데이터 테스트를 읽을 때 쉽고 따라가기 좋을만한 데..

제네릭을 머리로는 이해하고 있었는데 코드로 쳐본적이 없다 보니 좀 헷갈렸다. 아래처럼 쓰면 된다. public class Main { public static void main(String[] args) { ValueClass stringValueClass = new ValueClass("asd"); System.out.println(stringValueClass.getValue()); ValueClass integerValueClass = new ValueClass(123); System.out.println(integerValueClass.getValue()); ValueClass booleanValueClass = new ValueClass(true); System.out.println(boolea..

public class TestClass { public String getName() { return "yatyat2"; } } package com.example.tddstudy; import org.junit.jupiter.api.Test; import static org.assertj.core.api.Assertions.assertThat; import static org.mockito.Mockito.mock; import static org.mockito.Mockito.when; public class MethodMockTest { @Test void name() { TestClass testClass = mock(TestClass.class); when(testClass.getName()).t..

어떤 변수가 Function function; 이라는 것은 이 함수는 String을 인자로 받고, Interger를 반환한다는 의미이다. function을 초기화 할 때는 Function function = text -> 10; 같은 식으로 쓴다면 이 함수는 text라는 string을 받고, 10이라는 Integer를 반환한다는 의미이다.

개방 폐쇄 원칙은 기존 코드를 변경하지 않고, 기능을 추가할 수 있다는 원칙이다. 개방 폐쇄 원칙이란 객체를 다룸에 있어 확장은 개방적으로, 수정은 폐쇄적으로 대하는 원칙이다. 개방 폐쇄 원칙은 하나의 변화가 다른 곳에도 연쇄적으로 변화를 일으키는 것을 방지하기 위해 만들어졌습니다. 내가 작성한 코드중에 어기고 있는 코드는 없나? 아래 코드는 어떤 Policy에 대해 만족할 경우 그 Policy를 반환하는 클래스이다. 개방 폐쇄 법칙을 어긴 코드라고 할 수 있는데, 그 이유는 새로운 policy가 생길 때마다 클래스 내부의 코드를 바꾸어 줘야 하기 때문이다.(라고 생각한다) 그럼 바깥에서 Policy 리스트를 넘겨주는 게 바람직 한 것일까? 전략 패턴과 매우 관련이 깊어 보인다. 전략 패턴을 음... 좀..

유스케이스는 '내일'이면 다 변한다. 유스케이스를 '그때그때 작성하는 요구사항'이라고 생각해라. 유스케이스는 시스템의 동작 하나를 기술한 것이다. 사용자의 관점에서 작성하며, 사용자가 보낸 자극 '하나'에 대한 반응으로 시스템이 진행하는 '눈에 보이는' 이벤트 들의 흐름을 포착한다. 유스케이스는 오직 사용자가 직접 볼 수 있는 것을 적어 놓는다. 유스케이스의 이름을 기록하라. (세부사항이 아닌) 기본흐름(정상적인 동작), 대체흐름(세부 사항 가운데 잘못되는 경우)를 작성하라. 대체적으로 유스케이스는 간단하게 텍스트로만 기록하고, 다이어그램 같은건 그리지 말라고 하네.