신입개발자의 메모장

Execution failed for task ':test'.
> No tests found for given includes: [StringTest$Test3](filter.includeTestsMatching)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

이라는 에러 발생.

Settings -> Build,Execution,Deployment -> Gradle -> Run tests using -> From Gradle to IntelliJ IDEA 로 변경

*해결*

참고 : intellij idea - Intelij 2019.1 update breaks JUnit tests - Stack Overflow

***Junit5

*******************************************************Annotation

@BeforeAll,@AfterAll : 클래스에 있는 모든 메소드를 수행할 때 ,
메소드 수행전 , 후에 수행될 어노테이션이다.
@AfterEach,@BeforeEach : 특정 메소드가 시작되기 후, 전 마다 수행되는 어노테이션
@AfterEach : 다음 테스트에 영향을 주지 않기 위해 종료되어야할 리소스를 처리하는 부분
@BeforeEach : 테스트 할 때의 초기 환경을 setup
@Test : Junit이 수행할 코드 ,메소드에 붙음
@Nested : 연관 테스트 함수를 묶어주고 , 중첩테스트클래스임을 나타내줌 (클래스 레밸)

@RepeatedTest : value 속성에 지정된 수 만큼 반복 ,name 속성에 {displayName} {currentRepetition} {totalRepetitions} 가 함께 쓰일 수 있음
@DisplayName : 테스트 이름 설정 ( 클래스 , 메소드 레밸 이며 주로 @Nested와 같이 쓰임 )

@DisplayName 사용이유

• 메소드명을 한글로 작성해도 언더바를 작성해야 해서 가독성이 좋지 않음
• @Nested 와 함께 쓰려면 클래스를 작성해야 하는데 @DisplayName 을 쓰는게 깔끔
• JUnit 개발자들은 영어가 모국어 수준일텐데도 @DisplayName 어노테이션을 추가했다는 점

@ParameterizedTest : 하나의 테스트 메소드로 여러 개의 파라미터에 대해서 테스트할 수 있습니다.

name 속성을 이용하여 파라미터를 받는 메소드들에게 이름을 지정해 줄 수 있습니다.

name속성 내부에 , {index}는 1부터 시작되며 1씩증가

{arguments}는 모든 파라미터들을 출력

{0}은 첫번째 인수 , {1}은 두번째 인수 , ....
@ValueSource : 리터럴 값의 단일 배열을 지정할 수 있으며 매개 변수화 된 테스트 호출마다 단일 인수를 제공하는 데만 사용할 수 있습니다. @ParameterizedTest 와 함께 쓰임
@CsvSource : ValueSource의 확장판 ,여러 인자를 delimeter(구분자)로 구분해서 넘겨줌.

@ParameterizedTest 와 함께 쓰임

@NullSource @EmptySource : @NullSource @EmptySource 를 사용하면 파라미터 값으로 null과 empty를 넣어줍니다.

@ParameterizedTest 와 함께 쓰임

@NullAndEmptySource : null과 빈 공백을 파라미터값으로 넣어줍니다.

@ParameterizedTest 와 함께 쓰임

example1)  ValueSource 인수로써 문자열은 strings 로 , 정수형은 ints 형으로 하고 , method의 인자인 name으로 하나씩 들어감

 @ParameterizedTest
 @ValueSource(strings = {"q", "qwerasdfzxcv", "qq23"})
 void method(String name){

     ~

 }

example2) CsvSource 의 두번째 문자열내부의 tEst 와 test 이  method 인자의 input, expected에 각각 들어감

@ParameterizedTest
@CsvSource(value = {"test:test", "tEst:test", "Java:java"}, delimiter = ':')
void method(String input, String expected) {
    String actualValue = input.toLowerCase();
    assertEquals(expected, actualValue);
}

*******************************************************method

assertThat :
대부분의 경우 , 메서드 체이닝할 수 있어서 기존 assertXXX 메서드보다 더 많은 유연성을 제공.
예를 보자.

contains : 중복여부, 순서에 관계 없이 값만 일치하면 성공(expected가 actual에 포함되기만 하면 성공)

example) contains 예제
List<Integer> list = Arrays.asList(1, 2, 3);

// Success: 모든 원소를 입력하지 않아도 성공
assertThat(list).contains(1, 2);

// Success: 중복된 값이 있어도 포함만 되어 있으면 성공
assertThat(list).contains(1, 2, 2);

// Success: 순서가 바뀌어도 값만 맞으면 성공
assertThat(list).contains(3, 2);

// Fail: List 에 없는 값을 입력하면 실패
assertThat(list).contains(1, 2, 3, 4);

containsOnly : 순서,중복를 무시하는 대신 원소값과 갯수가 정확히 일치

containsExactly : 중복없어야 하고 , 순서를 포함해서 정확히 일치

assertThatThrownBy : 예외처리를 가독성 있게 테스트할 수 있는 함수제공.
assertThatThrownBy(() -> { 예외발생; }).isInstanceOf(예외종류.class)
.hasMessageContaining(예외문구);

assertThatExceptionOfType : assertThatThrownBy 와 비슷하다.

isEqualTo : actual 와 expected가 동일하면 통과
example)
assertThat(actual).isEqualTo(expected)

legacy assert 메소드

참고 : https://sas-study.tistory.com/314
https://jongmin92.github.io/2020/03/31/Java/use-assertthat/ (assertThat)
https://bcp0109.tistory.com/317 ( containsXXX)
https://bcp0109.tistory.com/297 ( @Nested , @DisplayName )

JUnit 5 알아보기 (tistory.com) ( @Nested )
https://pjh3749.tistory.com/m/241 ,
https://velog.io/@new_wisdom/assertJ-%EA%B3%B5%EC%8B%9D%EB%AC%B8%EC%84%9C%EC%99%80-%ED%95%A8%EA%BB%98%ED%95%98%EB%8A%94-assertJ-%EC%A0%95%EB%A6%AC 

( assertThatThrownBy , assertThatExceptionOfType)
https://pjh3749.tistory.com/241 ( isEqualTo )

https://dublin-java.tistory.com/56 ( @ParameterizedTest , @ValueSource , @NullAndEmptySource)

https://velog.io/@max9106/JUnit5-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EB%B0%98%EB%B3%B5-%ED%95%98%EA%B8%B0

https://www.baeldung.com/parameterized-tests-junit-5 ( @CsvSource )

https://beomseok95.tistory.com/205 ( assert 메소드모음 )

JUnit 5 Parameterized Tests 사용하기 (tistory.com) @NullSource @EmptySource
https://effortguy.tistory.com/116 (RepeatedTest)

레거시로 Log4J 를 많이 이용했었지만 , 
대체 Logger들이 많아졌음
스프링은 기본적으로 , commons.logging(jcl) (legacy) 라이브러리이용

상관도

jcl , SLF4J : 로그 인터페이스 

log4j : jcl 의 구현체

Logback : SLF4J의 구현체

내가 이용하고자 하는 Logback(SLF4J구현)라이브러리
-commons-logging 라이브러리를 제외 시켜야 함
-commons-logging 가 제외되면 ,기존 jcl을 통해 로그를 남기던
코드들은 에러 발생하는데 , jcl-over-slf4j라이브러리가 Log4j(jcl)와 SLF4J을 이어주는 징검다리 역할을 하여 출력시킴
- logback-classic 라이브러리가 로그를 남기게된다

필요한 dependencies

*jcl-over-slf4j

*logback-classic

로그정보

로그 순위 (오른쪽일 수록 심각) : trace debug info warn error  

에를들어 , 프로젝트 로그 레밸을 info 로 지정하였다면 , 로그 출력은 info warn error 

참고 : https://victorydntmd.tistory.com/173 

상세한 설명 : https://goddaehee.tistory.com/45 

view 에서, <link rel="shortcut icon" href="#"> 처럼 태그에 빈 값이 걸려있으면 두 번 돌아간다.

해당 태그를 삭제해주거나 값을 넣어주면 해결된다

본인은 Spring security 3.1.7 을 사용하였고 , 

Security 를 적용하기전에 , 공부하면서 정리해 보았다

21/07/28 )

본인은 기본 세션과 쿠키를 이용하여 로그인처리, 로그인 유지를 프로그래밍 하였으나 ,

시큐리티를 적용하여 마이그레이션 해보고자 함

내 플젝의 요구사항

1.  url 에 접근권한 설정
2. 로그인 권한이 필요한 url로 이동할 시 , 로그인페이지로 이동후 로그온되면 , 다시 첫 url로 이동
3.  사용자에 의하여 로그인 페이지로 이동후 로그인 시 , 메인페이지로 이동
4. 로그인 유지기능을 remember me 이용하여서 구현
5. jsp 파일에서 로그인정보를 가져올 경우엔 , security taglib 이용하여 정보 획득하기
6. 로그아웃 구현

2.  로그인 권한이 필요한 url로 이동할 시 , 로그인페이지로 이동후 로그온되면 , 다시 첫 url로 이동

(사용자의 요청을 저장하고 꺼내올수 있는)RequestCache 인터페이스를 이용하여

사용자 요청 정보들이 들어 있는 SavedRequest 클래스 객체를 세션에 저장

로그인화면을 보기전에 방문했던 URL을 가져오기

5 . jsp 파일에서 로그인정보를 가져올 경우엔 , security taglib 이용하여 정보 획득하기

( pom 에 등록한 spring-security-taglibs 이용하여 jsp 에서 세션 바로 이용)

로그인 성공 -> Authentication에 자동으로 사용자 정보 담김 -> .jsp 파일내 taglib 를 이용하여 세션 정보 도출

<sec:authentication property="name" var="Session_userID"/> 을 이용하여 시큐리티 이전에 사용하였던 세션 아이디를 이용함

class 에선

Authentication authentication
String Session_userID=(String)authentication.getPrincipal();  을 이용하여 id 획득

(주의)

in class)로그인하지 않았다면 , Authentication 객체에 담긴게 없게 되고 , authentication 호출하면 null이나옴
in jsp)<sec:authentication property="name" var="Session_userID"/> -> 등록된게 없으면 ,anonymousUser 가 나옴

1. url 에 접근권한 설정

security xml 설정

(url리소스)
정회원권한

/*/contentView/delete  (Authentication 와 게시글 id 비교)
 /*/contentView/update(get&post) (이하동문)
/*/contentView/updateBoard(이하동문)
/*/contentView/replyBoard(get&post) (Authentication 존재여부)
/*/contentView/deleteComment(Authentication 와 댓글 id 비교)
 /*/contentView/registerComment(Authentication 존재여부)
(요약)=> /*/contentView/**
 /*/write(get&post) 

/*/contentView/asyncGood

비회원권한
 /**

문제발생점

 /*/write 페이지에서 ->post 방식에서 세션 만료후 , 글등록을 누르면 -> login 창으로 이동후 로그인 -> 등록은 되는데 이상하게 되는 문제 발생

해결점
  세션만료된 POST 방식의 경우 로그인성공핸들러에서 sendRedirect 를 무시하게함 ( HTTP 메소드를 이용하여 구현 ) 
-> 웰컴페이지로 이동 ( default-target-url="/")

특이사항

/*/contentView/asyncGood 는 ajax 요청 url 이다 , 

비로그인 상태에서 해당 링크를 클릭 하면 , 로그인 페이지로 이동할 줄 알았으나 이동하지 않음 

개인적인 생각으로는 ,  서버의 produces 와 클라이언트의 dataType이 이미 JSON 으로 정해져 있으므로 ,

로그인 페이지가 나오지 않은 것으로 보인다..

그럼에도 보안성을 위해서 security xml 에 등록을 하였다

3 사용자에 의하여 로그인 페이지로 이동후 로그인 시 , 메인페이지로 이동

security xml 내부에

default-target-url="/" 로 설정하여 구현하였음

6 로그아웃 구현

4 로그인 유지기능을 remember me 이용하여서 구현

1. 쿠키만을 이용하는 방법 (Simple Hash Cookie)  - 이용

2. DB에 저장된 데이터를 이용해 쿠키를 이중 인증하는 방법 (Persistent 기반)

1 2 3 4 5 6 7 8 9 10 11

<http>     ...     <logout         ..                     delete-cookies="SPRING_SECURITY_REMEMBER_ME_COOKIE,Cookie_userID"     />     <remember-me         key="keyforHashde_endcoding"         token-validity-seconds="604800"     /> </http> Colored by Color Scripter

cs

 

8줄의 key 값은 암호화된 쿠키를 암/복호화 하는데 이용되는 key 값이다

쿠키의 유효시간을 일주일로 잡아주었다(9줄)

로그인html 에서 자동로그인 체크박스의 name="_spring_security_remember_me" 로 잡아주었다

 

특이점

In class) authentication.getPrincipal() 은 사용자의 ID 를 반환해 주었다 , 하지만,

REMEMBER ME 가 적용된 상태에서 -> 자동로그인으로 로그인 -> 서버재실행 -> authentication.getPrincipal() 은 UserinfoVO객체 반환이 되었다

나는 아이디가 필요하였기에 , authentication.getName으로 변경하여 해결 하였지만 ...

개인적인 생각으로는 , 서버가 다운되면 자동으로 Security Context Holder 내부의 Authentication도 초기화가 될 것이고 , 그렇다면 쿠키를 가져와 쿠키내용을 토대로 VO객체 생성후, Authentication 객체 생성에 이용되는 것이 아닐까? 하고 생각해본다.. 두서가 없구나 ㅠㅠ 공부부족이다

 

 

참고 : todyDev :: Spring Security - 로그인 성공 후 부가 작업 (tistory.com) 

spring security 파헤치기 (구조, 인증과정, 설정, 핸들러 및 암호화 예제, @Secured, @AuthenticationPrincipal, taglib) (tistory.com)

스프링 Security_로그인_자동 로그인(Remember-me) [8/9] (tistory.com) 

12. spring security remember me 기능 추가 (tistory.com)

https://djunnni.gitbook.io/springboot/2019-11-30

모든 부가 설치파일들은 의존성(dependency) 관련 버전을 반드시 확인해야 한다.

부가 설치파일과 스프링버전이 꼭 일치하는 것이 아니기 때문에 , 의존성에 맞는 버전을 사용하면 된다.

MVN Repository 에서 Compile Dependencies 을 확인해야한다

계기

1. client -> server 로 오는 url 을 매핑 시켜줄 때도 프로젝트명을 고려해야 하는 번거로움

2. resource , css , js 등 ViewResolver를 타는 것들 역시 프로젝트명을 신경써줘야함

3. 기본 url 이 '로컬호스트(혹은 IP주소):포트번호' 인데 , 모든 url요청에 일일히 프로젝트명을 넣어줘야하는 번거로움

4. 상대경로 url 요청을 절대경로 url 요청으로 변경하다보니 프로젝트명 제거의 필요성을 느끼게됨

원인

WAS 내부의 PATH 경로 값이 자동으로 'http://localhost:8090/PATH값' 을 베이스로 잡음

해결

PATH 값을 '/' 로 변경시켜줄 것

톰켓 서버 접속후 , 하단 Modules 클릭

설정변경할 프로젝트 선택후 , Edit 클릭

Path 경로를 '/' 로 변경

프로젝트명없이 실행됨

-jsp:include 를 이용하는 경우

jsp:include에 대한 설명 https://sesok808.tistory.com/331

jsp:include action 방식 참고 사이트 : https://all-record.tistory.com/106 

사용법 ex)

<jsp:include page="common/nav.jsp" flush="false"/> 

<!-- page: 이동할 jsp 파일을 의미 ,  flush: jsp:include태그를 읽는 시점에 , 현재까지 저장된 출력버퍼를 비울지 여부-->

<!-- 보통은 false 시켜 놓는다 -->

-Jquery 를 이용하는 경우 , Javascript의 Ajax를 이용하는 경우

https://kyung-a.tistory.com/18

-MVC 프레임워크-

*프론트 컨트롤러 패턴

-기존의 컨트롤러들의 앞에 공통컨트롤러(서블릿)을 놓는것

-공통처리기능

-프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨

-스프링 웹 MVC의 DispatcherServlet이 FrontController 패턴으로 구현되어 있음

request.getRequestURI(); // http://localhost:8080 이후 부분만 호출 된다 ex) /front-controller/v1/hello

"/front-controller/v1/*" : /front-controller/v1 를 포함한 하위 모든 요청은 이 서블릿에서 받아들인다

실제 개발의 대부분의 경우에 절대경로를 사용하는 것이 좋다

스프링자체가 싱글톤을 보장해줘서 , 스프링내에선 싱글톤 안써도 됨

-Junit5

@AfterEach,@BeforeEach :  테스트가 시작되기 후, 전 마다 수행되는 어노테이션

@AfterEach// 메소드에 붙음 , 다음 테스트에 영향을 주지 않기 위해 종료되어야할 리소스를 처리하는 부분

@BeforeEach// 메소드에 붙음 , 테스트 할 때의 초기 환경을 setup

@Test//Junit이 수행할 코드 ,메소드에 붙음

given (ㅇㅇ 주어졌을때) -> when (ㅇㅇ 실행했을때 ) -> then (결과가 ㅇㅇ 이어야되) 로직으로 수행됨

then부분 ex)

Assertions.assertThat(출력값).isEqualTo(기댓값);

Assertions.assertThat(컬렉션객체).contains(member1,member2);

( Junit 5 기준 명령어 참고 )

템플릿 엔진(뷰 템블릿) : html 에다가 자바코드를 중간중간 삽입하는 것 , jsp(legacy) 타임리프(new)

정적 HTML 문서 : 항상고정된 HTML

동적 HTML 문서 : 시시각각 변화되는 회원목록같은 HTML

동적 HTML case : 서블릿+자바내부 html (very old) ,  템플릿 엔진단독 이용 , 서블릿+템플릿엔진(new)

-JSP

JSP도 서블릿으로 변환됨, 따라서  request, response를 사용가능함

JSP는 자바코드를 그대로 다 사용할 수 있다.

JSP는 <% ~ %> 에 자바코드를 입력할 수 있다

<%= ~ %> 에서는 자바코드를 출력한다

-서블릿과 JSP의 한계

서블릿만으로 뷰화면을 만들려면 ,  자바코드 내부에 html 을 써줘야한다는 불편함이 존재

서블릿과 JSP로 뷰화면을 만든다면 , 뷰파일에 자바영역과 , HTML 영역이 둘다 존재 ( 커밋시 문제 , 역할이 너무많음 , 유지보수의 지옥 ) 

=> MVC 패턴의 등장 (보여주는것과 비즈니스로직과의 분리) ( JSP는 뷰를 그리는 것에만 집중하게함 )

변경의 라이프사이클이 다른것들(비즈니스로직,UI)을 분리해주는것이 유지보수에 좋다

-MVC 패턴1(legacy)
컨트롤러(Servlet): 비즈니스 로직을 다 수행 , Model에 데이터를 담음 , 뷰로 제어권을 넘김

모델(Model)객체 : 데이터담기는 곳
뷰(ex JSP): Model에 있는 데이터를 참고해서 뷰를 완성하고 , 클라이언트에게 보냄

-MVC 패턴2(new)  ( CS 에서 배웠던 부분과 약간 다르지만 , 뭐 비슷하다 )

컨트롤러 : HTTP요청이 옳바른지 스펙을 확인 , 서비스 호출 , 종합적인 조종역할

서비스,리포지토리 : 비즈니스 로직, 데이터 접근 수행

모델(Model)객체 : 데이터 담기는 곳

뷰(ex JSP): Model에 있는 데이터를 참고해서 뷰를 완성하고 , 클라이언트에게 보냄

Servlet을 컨트롤러로 , JSP 를 뷰로처리

request.setAttribute 는 임시저장소 지만 , Model에 데이터가 들어감

컨트롤러에서는 HttpServletRequest객체.setAttribute("이름","값") 으로 Model에 데이터를 넣을수 있고,

뷰에서는 request.getAttribute("이름")로 Model에서 데이터를 꺼낼 수 있다

RequestDispatcher dispatcher =request.getRequestDispatcher(jsp파일경로문자열);//Controller->view 로 이동할때 사용
dispatcher.forward(request,response); //  다른 서블릿이나 JSP로 이동할 수 있는 기능 , 서버내부에서 다시 호출이 발생                                                       ,리다이렉트(웹브라우저에 갔다가 서버로 재요청)와 다르게 서버내부이동임,

                                                      Client->Server->Servlet 의 dispatcher->jsp->client

경로 ex)  현재 페이지 : http://localhost:8080/servlet-mvc/members/new-form

상대경로 : 클라이언트에서 save 호출시 -> http://localhost:8080/servlet-mvc/members/save

절대경로(추천) : 클라이언트에서 /save 호출시 -> http://localhost:8080/save

WEB-INF 폴더 : WEB-INF 내부에 있는 파일들은 컨트롤러를 거쳐야지 불려 질수 있음 ( 외부에서 호출 불가능 )

-redirect vs forward

redirect : client에 응답이 나가고 , HTTP헤더의 로케이션값으로 다시 서버에 요청하면서 로케이션값이 

            웹 브라우저의 url로 변경이됨 , 즉 server->client 가 두번 발생

forward : 서버 내부에서 일어나는 호출이기때문에 클라이언트가 전혀 인지하지 못함

jsp에서 request.getAttribute("이름") 으로 모델객체내용을 받을 수 있지만 너무 김 , 대신에..

${이름.필드변수} 로 바로 호출 가능  (프로퍼티 접근법, 필드변수만 적으면 상황에 맞게 자동으로 get or set이 호출)

jsp 선언부에 <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> 를 호출 하여 jstl 이용가능

MVC 패턴에서 , client에서 오는 요청은 무조건 먼저 Controller를 거친다 ( 규칙 ) 

-MVC 패턴의 한계 ( jsp 와 servlet 만으로 구현한 mvc 패턴 )  

컨트롤러내의 dispatcher 중복

viewPath="/WEB-INF/views/members.jsp" 의 내용중복

HttpServletRequest , HttpServletResponse 객체들이 꼭 사용되는 것은 아님 , service메소드 인자로 항상 쓰인다는 문제

공통처리가 어렵다 ( 로그처리 , 각종 중복코드 , 중복호출문제 )

=>

프론트 컨트롤러 패턴 : client 로부터 요청이 올때 다양한 공통처리를 미리 설계 해주는  객체(수문장역할)를 경유하여 서블릿으로 통하게 하는 방식 ( SPRING MVC 의 핵심 ) ,

대표컨트롤러를 두어 이후 나오는 컨트롤러들이 호출되게함