[필기노트] 2021-07-22 SQL, 태그 검색, 테스트코드

-- 검색 API에서 태그검색 기능 추가 

1. 태그 테이블 전체를 조회한다.
SELECT * FROM Tags
;

2. 태그 테이블에서 해당하는 키워드로 검색해 본다.
SELECT * FROM Tags WHERE tag LIKE '%na%'
;

3. 검색된 태그 테이블에서 postId만 추출한다.
SELECT postId FROM Tags WHERE tag LIKE '%na%'
;

4. 검색 코드에서 WHERE 절에 서브쿼리를 삽입해 병합을 종료한다.
SELECT u.userId, u.nickname, u.profileImg, p.postId, p.reBlog, p.title,
(SELECT GROUP_CONCAT(img ORDER BY img ASC SEPARATOR ', ')
    FROM Images
    WHERE postId = p.postId
    GROUP BY postId) AS img,
p.content,
(SELECT GROUP_CONCAT(tag ORDER BY tag ASC SEPARATOR ', ')
    FROM Tags
    WHERE postId = p.postId
    GROUP BY postId) AS tag,
CASE WHEN p.postId IN (SELECT postId FROM Favorites WHERE userId=1) THEN "Y" ELSE "N" END AS favorite,
(SELECT COALESCE(MIN('Y'), 'N')
    FROM Follows
    WHERE EXISTS (SELECT 1 FROM  Follows WHERE followUserId = 1 AND followerUserId=p.userId)) AS follow,
(SELECT COUNT(*) FROM Favorites WHERE postId=p.postId) +
    (SELECT COUNT(*) FROM Posts WHERE reBlog=p.postId) AS reactionCount,
p.createdAt
FROM Posts AS p
INNER JOIN Users AS u
USING(userId)
WHERE p.title LIKE '%na%' 
    OR p.content LIKE '%na%' 
    OR postId IN (SELECT postId FROM Tags WHERE tag LIKE '%na%')
ORDER BY p.createdAt DESC
LIMIT 0, 30
;

 

 

== Chapter 5 품질보증

QA
 - 해야할 일을 파악하는것
 - 그 일이 확실히 이루어지게 하는 것
 - 포괄적이고 반복 가능한 QA 계획을 수립하는 일
 - [프로젝트가 의도한 대로 동작하도록 하기 위해 취한 단계 전체를 기록하는 것]

QA 계획을 업데이트 해야할 경우
 - 새로운 기능 추가
 - 기존 기능의 변경
 - 기능 제거
 - 테스트 기술이나 테크닉의 변경
 - QA 계획에서 놓친 버그


품질의 관점
 - 점유율 : 시장에 얼마나 영향력을 끼치는지
    - 웹사이트를 이용하는 사람, 서비스를 사용하는 사람의 숫자
    - 수익에 직접적인 영향
    - 개발자의 관점에서는 검색엔진 최적화(SEO)가 점유율에 가장 큰 영향
 - 기능
    - 테스트 자동화로 평가하면 가장 좋다.
 - 사용성
    - 사람과 컴퓨터의 상호작용 (Human-ComputerInteraction (HCI))를 평가한다.
    - '이 기능이 대상 수요자에게 유용한 형태로 전해지는가?'
    - 사용성을 평가할 때는 반드시 대상 수요자의 입장에서 생각해야 한다.
    - QA 계획에는 사용자 테스트를 꼭 넣어야 한다.
 - 미학
    - QA 계획에는 주기적인 평가가 들어있어야 한다.
    - 대중적인 기준 역시 시간이 지나면 변할 수 있다.


테스트 타입
 - 단위 테스트 : 구성 요소 하나가 정확히 동작하는지 테스트하는 세밀한 테스트
    - 로직 테스트에 더 적합
 - 통합 테스트 : 여러 구성 요소, 심지어 시스템 전체의 상호작용을 테스트
    - 로직과 표현에 모두 적용할 수 있다.


단위 테스트
 - 어플리케이션에 존재하는 가장 작은 기능 단위, 보통 함수를 테스트
 - 단위테스트의 핵심은 함수나 구성요소를 고립시키는 것
 - 개발자가 작성 / Jest를 사용

통합 테스트
 - 애플리케이션의 여러 부분 (함수, 모듈, 서브시스템 등)의 더 큰 기능 단위를 테스트
 - 최종적인 통합 테스트는 애플리케이션을 브라우저에서 렌더링하고
 - 브라우저를 조작하면서 어플리케이션이 의도한 대로 동작하는지 확인
 - 퍼펫티어, Jest

린트
 - 잠재적인 오류를 찾는 작업
 - 오류가 일어날 수 있는 부분, 나중에 오류로 연결될 수 있는 취약한 구조를 찾는다.
 - es린트


테스트 프레임워크의 종류
 - Jest, Mocha, Jasmine, Ava, Tape

Jest
 - npm install --save-dev jest
    - 개발 단계에서만 사용하는 패키지, 어플리케이션 자체의 동작에는 필요하지 않다.
 - package.json에서 script > "test": "jest"로 수정
 - $ npm test : 프로젝트의 테스트를 전부 실행할 수 있다.
    - test를 제외한 다른 스크립트를 실행할 경우 
     ex) npm run test3

 - test() : 단위 테스트를 묶어주는 함수
 - expect() : 특정 값이 만족되는지(정상적인지) 확인하기 위한 표현식을 작성할수 있게 해주는 함수입니다.


 - 렌더링을 시작하려면 요청과 응답 객체가 필요
 - 렌더링에서 사용할 부분은 res.render만 필요하기 때문에 const res= { render : jest.fn() } 으로 정의한다.
 - jest.fn() : 어떻게 호출됐는지 추적하는 범용 모형 삼수
 - Jest의 모형 함수는 자신이 호출되었을 때를 항상 추적
 - res.render.mock.calls[0] : 첫번째로 호출된 상황
 - res.render.mock.calls[0][0] : 전달받은 매개변수 중 첫 번째

 - expect().toBe :정확한 일치하는 것을 테스트하기 위해 Object.is를 사용한다.

 - expect().toEqual : 오브젝트 또는 배열의 모든 필드 값을 재귀적으로 체크한다.

 - expect().not.toEqual : 일치하지 않는것을 체크한다.

 - expect().toBeNull : Null 
 - expect().toBeUndefined : Undefined
 - expect().toBeDefined : Defined
 - expect().toBeTruthy : if 문이 true로 간주하는 모든 항목과 일치
 - expect().toBeFalsy : if 문이 false로 간주하는 모든 항목과 일치

 - expect().not.toBeNull : Null이 아닌경우 체크한다.

 - expect().toThrow() : 코드내부에서 Error를 Throw하는것을 테스트
 





supertest를 위한 계정 생성
$ docker exec -it test-db bash

$ mysql -u root -p

$ CREATE USER 'root'@'172.17.0.1' IDENTIFIED BY '1234';
 - supertest에서 자동설정된 계정으로 로그인하기 위해 계정을 생성한다.

$ GRANT ALL PRIVILEGES ON *.* TO 'root'@'172.17.0.1' WITH GRANT OPTION;
 - 계정에 모든 권한을 주기 위해 설정

$ flush privileges;
 - 데이터베이스의 권한을 INSERT, UPDATE, DELETE로 수정했을 때 바로 반영이 되게 설정함