Knex: Knex를 사용하는 메서드에 대한 단위 테스트를 작성하는 방법.

"knex.js를 사용하여 원자 단위 테스트를 작성하는 방법"을 다시 시도하고 흥미로운 결과를 얻고 있었기 때문에 어젯밤 인터넷 검색을 제대로 수행하지 않은 것 같습니다. 지금 읽어 보겠습니다. 내가 뭔가를 배우면 다시 게시 할 것입니다.

아니요-아무것도 얻지 못했습니다. 출처의 연대순으로 요약 :

2016-04-21 https://medium.com/@jomaora/knex -bookshelf-mocks-and-unit-tests-cca627565d3

전략 : mock-knex를 사용하십시오. DB를 모의하고 싶지 않습니다. 올바른 동작을 보장하기 위해 실제 MySQL DB에 대해 내 메서드를 테스트하고 싶습니다.하지만 어쨌든 mock-knex 살펴 보았습니다 ... 최악의 설계 라이브러리 일 수 있습니다. 나는 만난 적이 있습니다. :(

2016-04-28 http://mherman.org/blog/2016/04/28/test-driven-development-with-node/

전략 : 각 테스트 후 DB를 롤백 / 재 마이그레이션 / 재 시드합니다. 이는 각 테스트에 대해 엄청난 오버 헤드처럼 보이며 매우 느리게 실행됩니다. 각 테스트의 DB 이름에 대한 UUID를 생성하여 동시성을 달성 할 수 있지만 트랜잭션의 우아함에 비해 끔찍한 솔루션 인 것 같습니다.

2015-09-23 http://stackoverflow.com/a/32749601/210867

전략 : 테스트에 sqlite를 사용하고 각 테스트에 대해 DB를 생성 / 파기합니다. 위의 접근 방식이 마음에 들지 않는 두 가지 이유를 모두 다루었습니다.

따라서 ... 제안을 구하고 Knex 트랜잭션이 실제로 작동하는 방법에 대한 추가 지침과이를 내 사용 사례에 적절하게 적용하는 방법에 대한 추가 지침을 구하고 있습니다.

@odigity 는 나쁜 테스트 관행을 멋지게 요약했습니다 👍

다음과 같이 "단위"테스트를 수행합니다.

1. 시스템 시작, DB 초기화 및 마이그레이션 실행

2. 각 테스트 전에 모든 테이블과 시퀀스를 자릅니다 (knex-db-manager 패키지 사용).

3. 테스트 케이스에 필요한 데이터 삽입 (단일 명령으로 중첩 된 객체 계층 구조를 삽입 할 수있는 knex 기반 objection.js ORM을 사용하며, 각 행에 대해 별도의 삽입을 수행 할 필요가 없도록 삽입을 최적화하는 방법을 알고 있습니다. 테이블에 있지만 일반적으로 테이블 당 하나의 삽입 만)

4. 1 개의 테스트를 실행하고 2 단계로 이동

e2e 테스트에서는 saveState / restoreState (pg_restore / pg_dump 사용) 메서드를 구현하여 테스트 실행 중에 특정 상태로 롤백 할 수 있으므로 20 실행 후 일부 테스트가 실패 할 때마다 테스트 실행을 다시 시작할 필요가 없습니다. 몇 분의 테스트.

어제 시작했던 것과 비슷합니다. 간단하고 간단하고 발전해야했기 때문입니다.

모든 테이블 자르기에 대한 빠른 대안으로 트랜잭션에서 테스트를 래핑하고 롤백하는 전략을 고려 했습니까? 구현을 파악할 수 있다면 그것은 나에게 이상적인 것처럼 보입니다.

동일한 프로세스에서 db와 애플리케이션 코드를 실행하면 테스트 코드에서 트랜잭션을 생성 한 다음 해당 트랜잭션을 knex-instance로 등록 할 수 있다고 가정합니다 (knex 인스턴스와 트랜잭션은 경우에 따라 약간 다르게 보이지만 일반적으로 트랜잭션을 사용할 수 있습니다. 일반적인 knex 인스턴스와 같은 인스턴스).

그런 다음 일반 풀링 된 knex 인스턴스 대신 트랜잭션을 가져오고이를 통해 쿼리를 시작하는 애플리케이션 코드를 시작합니다.

OP에서 설명한 것과 거의 동일합니다. 당신이 그것을 설명하는 방법은 실행 가능하게 들립니다.

몇 년 전에 테스트에서 DB를 재설정하기 위해 트랜잭션을 사용하는 것을 고려했지만 앱에서 작동하는 것과 거의 동일한 방식으로 테스트에서 작동하기 위해 연결 풀링을 원했기 때문에 거부했습니다 + 자르기 / 초기화가 충분히 빠릅니다.

하나의 일괄 처리에서 실행되는 모든 쿼리가 동일한 연결을 사용하여 단일 트랜잭션으로 래핑 될 수 있도록 트랜잭션 기간 동안 연결 선호도를 달성 할 수있는 방법이 없습니까?

자르기 전략은 효과가 있지만 매우 무차별 적입니다. 현재 각 테스트 파일에 test.after.always () 후크가있어 해당 파일의 테스트에 영향을받는 테이블 (일반적으로 파일 당 하나의 테이블)을 잘라내지만 그로 인해 망가질 수있는 가장자리 사례를 생각할 수 있습니다.

예를 들어, 동일한 테이블을 터치하는 서로 다른 테스트 파일의 두 테스트가 거의 동시에 실행되는 경우 두 번째 파일의 테스트가 실행되는 동안 한 파일의 자르기 후크가 시작되어 해당 테스트를 망칠 수 있습니다.

마지막으로, Knex에서 트랜잭션이 정확히 어떻게 작동하는지 아직 명확하지 않습니다. knex.transaction() 로 trx 를 생성하면 trx 사용하여 실행되는 모든 쿼리가 자동으로 트랜잭션의 일부가됩니까? 수동으로 커밋 / 롤백해야합니까? (발생 오류가 없다고 가정합니다.)

하나의 일괄 처리에서 실행되는 모든 쿼리가 동일한 연결을 사용하여 단일 트랜잭션으로 래핑 될 수 있도록 트랜잭션 기간 동안 연결 선호도를 달성 할 수있는 방법이 없습니까?

나는 이것을 이해하지 못했다

자르기 전략은 효과가 있지만 매우 무차별 적입니다. 현재 각 테스트 파일에 test.after.always () 후크가있어 해당 파일의 테스트에 영향을받는 테이블 (일반적으로 파일 당 하나의 테이블)을 잘라내지만 그로 인해 망가질 수있는 가장자리 사례를 생각할 수 있습니다.

예를 들어, 동일한 테이블을 터치하는 서로 다른 테스트 파일의 두 테스트가 거의 동시에 실행되는 경우 두 번째 파일의 테스트가 실행되는 동안 한 파일의 자르기 후크가 시작되어 해당 테스트를 망칠 수 있습니다.

트랜잭션을 사용하여 테스트 데이터를 재설정하더라도 일반적으로 여러 테스트를 병렬로 실행할 수 없습니다. ID 시퀀스가 ​​다르며 트랜잭션이 교착 상태가 될 수 있습니다.

마지막으로, Knex에서 트랜잭션이 정확히 어떻게 작동하는지 아직 명확하지 않습니다. knex.transaction ()으로 trx를 생성하면 trx를 사용하여 실행되는 모든 쿼리가 자동으로 트랜잭션의 일부가됩니까? 수동으로 커밋 / 롤백해야합니까? (발생 오류가 없다고 가정합니다.)

이것은 문서에서 찾을 수 있습니다. knex.transaction(callback) 콜백에서 promise를 반환하지 않으면 수동으로 커밋 / 롤백해야합니다. 콜백이 promise를 반환하면 commit / rollback이 자동으로 호출됩니다. 귀하의 경우에는 수동으로 롤백해야 할 것입니다.

트랜잭션을 사용하여 테스트 데이터를 재설정하더라도 일반적으로 여러 테스트를 병렬로 실행할 수 없습니다. ID 시퀀스가 ​​다르며 트랜잭션이 교착 상태가 될 수 있습니다.

삽입하는 각 레코드에 대해 무작위로 ID를 생성하고 있습니다. 충돌은 가능하지만 가능성은 낮으며 언젠가 한 번 발생하면 고객 대면 코드가 아닌 테스트 일뿐입니다.

동시성에 관해서는 단일 트랜잭션으로 그룹화해야하는 모든 쿼리도 동일한 DB 연결을 사용해야한다고 가정합니다.이 연결은 Knex 풀 크기를 1로 설정하여 수행 할 수 있습니다. 그런 다음 A에서 테스트를 수행해야합니다. .serial 수정자를 사용하여 직렬 파일. 그러나 Ava가 별도의 하위 프로세스에서 각 테스트 파일을 실행하기 때문에 테스트 파일 (성능에 가장 중요한 요소) 간에 동시성

그냥 가봐야 할 것 같아요.

나는 그것을 작동했다!

https://gist.github.com/odigity/7f37077de74964051d45c4ca80ec3250

프로젝트에서 단위 테스트를 위해 Ava를 사용하고 있지만이 예제에서는 개념을 보여주기 위해 이전 / 이후 후크가있는 모의 단위 테스트 시나리오를 방금 만들었습니다.

후크 전

• 트랜잭션을 얻는 것은 비동기 작업이므로 before 후크에서 반환 할 새 Promise를 만들고 resolve 메서드를 캡처하여 transaction() 콜백에서 호출 할 수 있도록합니다.
• 거래를 시작합니다. 콜백에서 나는 ...
  
  
  
  • 테스트 및 after 후크에 액세스 할 수있는 위치에 tx 핸들을 저장합니다.
  
  
  • 저장된 resolve 메서드를 호출하여 "테스트 프레임 워크"에 before 후크가 완료되었음을 알리고 테스트를 시작할 수 있습니다.
  
  

테스트 — 저장된 tx 핸들을 사용하여 두 개의 삽입 쿼리를 실행합니다.

후크 이후 — 저장된 tx 핸들을 사용하여 트랜잭션을 롤백하므로 테스트 중에 이루어진 모든 변경 사항을 취소합니다. 데이터는 커밋되지 않기 때문에 다른 테스트의 활동에서 보거나 방해 할 수도 없습니다.

동시성

Knex

Knex를 사용하면 연결 풀 크기에 대한 옵션을 지정할 수 있습니다. 트랜잭션의 모든 쿼리가 동일한 연결에서 실행되도록해야하는 경우 (우리가 수행한다고 가정합니다) 풀 크기를 1로 설정하여이를 달성 할 수 있습니다.

_하지만 기다려 ..._ 소스 에서이 댓글을 확인하세요.

// We need to make a client object which always acquires the same
// connection and does not release back into the pool.
function makeTxClient(trx, client, connection) {

내가 이것을 올바르게 이해한다면 풀이 1보다 크더라도 트랜잭션의 모든 쿼리가 동일한 연결을 통과하도록 Knex를 신뢰할 수 있음을 의미합니다! 따라서 시나리오를 위해이 특정 수준의 동시성을 희생 할 필요가 없습니다.

BTW — 문서는 아마도이 필수적이고 놀라운 사실을 반영해야합니다.

Ava

_Knex 전용이 아니라 Ava 전용이라는 것을 알고 있지만 널리 사용되는 프레임 워크이며 대부분의 프레임 워크에 광범위하게 적용 할 수 있습니다 ._

Ava는 각 테스트 파일을 별도의 프로세스에서 동시에 실행합니다. 각 프로세스 내에서 모든 테스트를 동시에 실행합니다. --serial CLI 옵션 (모든 항목을 직렬화) 또는 test 메서드의 .serial 수정자를 사용하여 두 가지 형태의 동시성을 비활성화 할 수 있습니다 (나머지를 동시에 실행하기 전에 표시된 테스트를 직렬화 함). ).

요약

이 모든 사실을 종합하면 :

• 트랜잭션에서 각 테스트를 래핑 할 수 있으므로 (a) 테스트 데이터 충돌 방지 (b) 자르기 또는 다시 마이그레이션없이 자동 테스트 후 정리가 보장됩니다. 사실,이 전략을 사용하면 내 테스트 DB에는 필수 시드 데이터 외에는 말 그대로 단일 레코드가 유지되지 않습니다.

• 각 테스트 파일이 별도의 프로세스에서 실행되므로 자체 Knex 연결 풀을 갖게되므로 Ava의 테스트 파일 간 동시성의 이점을 계속 누릴 수 있습니다.

• 내 연결 풀인지 확인 만약 내가 에바의 내 testfile 위 동시성의 혜택을 계속할 수> = 파일의 테스트의 수. 이것은 하나의 파일에 엄청난 수의 테스트를 넣지 않는 문제가 아닙니다. 어쨌든 피하려고 노력합니다. 또한 풀은 1-10과 같은 범위로 설정할 수 있으므로 필요하지 않은 연결을 만들지 않지만 테스트를 추가하거나 제거 할 때마다 각 테스트 파일에서 상수를 조정할 필요가 없습니다.

나는 동시에 나에게 새로운 수많은 기술의 교차점에 손을 대고 있기 때문에 다른 사람들의 생각을 얻고 싶어합니다 ...

@odigity yup, BEGIN 쿼리를 추가하는 전용 연결에 대한 핸들 일뿐입니다 (실제로 SQL의 트랜잭션은 일반적으로 BEGIN이 추가 된 동일한 연결로가는 쿼리입니다).

knex가 트랜잭션에 대한 연결을 할당하지 않으면 트랜잭션이 전혀 작동하지 않습니다.

uuid 키를 사용하는 것도 나쁘지 않습니다. 실제로 행이 많지 않으면 충돌이 변경 될 가능성이 거의 없습니다. ( "128 비트 UUID를 사용하는 경우 '생일 효과'는 각 키에 128 비트 엔트로피가있는 경우 약 2 ^ 64 개의 키를 생성 한 후 충돌이 발생할 가능성이 있음을 알려줍니다.")

답을 알아 낸 것 같으니 이걸 닫으세요 👍

다시 열어서 미안하지만 이제 예상치 못한 동작을 관찰하고 있습니다. 특히, 작동하지 않아야 할 때 작동하므로 내 이해에 수정이 필요합니다.

풀 크기를 1로 설정하고 트랜잭션을 연 다음이를 사용하지 않고 쿼리를 실행하면 연결을 얻을 수 없기 때문에 시간이 초과됩니다. 이는 해당 연결이 이미 트랜잭션에 의해 잠겨 있기 때문입니다.

그러나 풀 크기를 1로 설정하고 4 개의 테스트를 동시에 실행하면 각 테스트는 다음과 같습니다.

• 거래를 시작하다
• 쿼리 실행
• 끝에 롤백 호출

모두 작동합니다. 작동하지 않아야합니다. 최소한 몇 개는 연결 부족으로 인해 잠겼어야합니다. 그러나 모두 정상적으로 작동합니다.

Knex에는 당시 사용 가능한 연결이없는 경우 쿼리를위한 기본 제공 대기열이 있습니까? 그렇다면 tx가 아닌 쿼리를 실행하기 전에 트랜잭션이 완료 될 때까지 기다리는 대신 첫 번째 예제가 실패하는 이유는 무엇입니까?

아니면 Knex는 어떻게 든 여러 동시 트랜잭션을 단일 연결로 다중화합니까?

아니면 Knex가 실제로 2 차, 3 차 및 4 차 호출에서 하위 트랜잭션을 생성하고 있습니까? 그렇다면 아마도 무작위로 예상되는 결과를 초래할 것입니다 ...

@odgity 첫 번째 경우에는 애플리케이션 측 교착 상태가 있습니다 (앱이 연결 대기 중 멈춤 및 연결 시간 초과 트리거 획득).

두 번째 경우 테스트는 실제로 직렬로 실행됩니다. 하나를 제외한 모든 사람이 연결을 기다리고 있기 때문입니다. 병렬로 수행하는 테스트가 충분하거나 테스트 케이스가 정말 느린 경우 acquireConnectionTimeout이 두 번째 경우에도 트리거되어야합니다.

단일 연결에서 트랜잭션을 다중화 할 수 없습니다. 중첩 트랜잭션은 트랜잭션 내부의 저장 점을 사용하여 knex에서 지원됩니다. 풀에서 새로운 트랜잭션을 요청하는 경우도 발생하지 않습니다.

감사합니다. 정말 도움이됩니다.

열린 트랜잭션에서 연결을 가져올 때 쿼리를 실행하는 이유에 대해 여전히 약간 혼란 스럽지만 두 번째 새 트랜잭션을 열려고 시도하면 참을성있게 기다렸다가 완료됩니다.

DEBUG = knex : * 환경 변수로 코드를 실행하면 풀이 어떤 일을하는지 알 수 있습니다. Knex는 첫 번째 경우에도 "I couldnt get connection"시간 초과가 발생할 때까지 기다려야합니다. 따라서 두 번째 연결이 획득 될 때까지 트랜잭션이 대기중인 경우 두 연결이 서로를 기다리고 있기 때문에 애플리케이션 수준의 교착 상태입니다 (하지만 이것이 귀하의 경우인지 모르겠습니다).

이 스레드가 매우 유용하다는 것을 알았습니다. 다른 사람들도 시스템 상태를 오염시키지 않는 테스트를 작성하는 데 관심이 있다는 것을 알게되어 기쁩니다. 나는 사람들이 테스트가 완료된 후 롤백되는 knex를 사용하는 코드에 대한 테스트를 작성할 수있는 프로젝트를 시작했습니다.

https://github.com/bas080/knest

일반적인 경우 @ bas080 은 테스트 할 수있는 항목을 제한합니다 (테스트가 단일 트랜잭션 만 사용하도록 허용). 다중 연결 / 동시 트랜잭션을 사용하는 코드 테스트를 방지합니다. 또한 이런 방식으로 암시 적 커밋을 수행하는 코드를 테스트 할 수 없습니다 (일반적인 경우는 아님).

트랜잭션을 사용하여 테스트를 실행 한 후 상태를 재설정하는 것은 매우 일반적인 패턴이라는 것을 알고 있습니다. 강조하고 싶은 것은 해당 접근 방식 만 사용하면 특정 항목을 테스트 할 수 없다는 것입니다.

나는 항상 데이터를 수정하는 각 테스트 후 또는 서로 의존하는 일부 테스트 세트 후에 DB를 자르고 다시 채우는 것을 선호했습니다 (50ms 이상처럼 채우기가 너무 오래 걸리는 경우 성능상의 이유로이 작업을 수행합니다).

안녕,이 문제를 다시 열어서 미안하지만 knex의 cli가 가짜 데이터로 여러 데이터베이스를 _seed하는 새로운 프로젝트를 시작 했습니다.

단위 테스트의 경우 쿼리 체인의 끝에 toString() 를 사용하여 SQL 래퍼에서 Knex가 실행 한 쿼리가 올바르게 구성되었는지 확인했습니다. 통합 테스트를 위해 이미 위에 나열된 전략을 사용했습니다. 즉, 모든 테스트 전에 롤백-> 마이그레이션-> 시드를 순환하는 것입니다. 시드 데이터를 작게 유지할 수 없으면 너무 느릴 수 있지만 다른 사람에게는 적합 할 수 있습니다.

즉, 모든 테스트 전에 롤백-> 마이그레이션-> 시드를 순환합니다.

그렇게하는 것은 정말 나쁜 방법입니다. 마이그레이션을 앞뒤로 실행하는 데 수백 밀리 초가 걸리기 때문에 너무 느립니다. 전체 테스트 스위트에 대해 마이그레이션을 한 번만 실행 한 다음 테스트 전에 모든 테이블을 잘라 내고 적절한 테스트 데이터를 채워야합니다. 전체 스키마를 롤백 / 재 작성하는 것보다 100 배 더 빠르게 수행 할 수 있습니다.

knex-cleaner 를 사용하여 모든 테이블을 쉽게

knexCleaner
    .clean(knex, { ignoreTables: ['knex_migrations', 'knex_migrations_lock'] })
    .then(() => knex.seed.run())

각 테스트 스위트 실행을 시작할 때 마이그레이션을 실행하는 경우 ignoreTables 부분을 ​​사용할 필요가 없습니다. 테스트 데이터베이스에서 수동으로 마이그레이션을 실행하는 경우에만 필요합니다.

@ricardograca 외래 키가있는 케이스를 잘 처리합니까? (삭제 순서가 잘못되어 청소가 실패하지 않음을 의미)

그렇지 않은 경우 수정하기 쉽습니다 (단일 쿼리로 모든 테이블을 잘라 내면됩니다). :)

@elhigu 어떻게 할 수 있습니까?

데이터베이스에 따라 다르지만 예를 들면 다음과 같습니다. https://github.com/Vincit/knex-db-manager/blob/master/lib/PostgresDatabaseManager.js#L95

@kibertoad 예, 외래 키 제약 조건을 잘 처리하고 모든 것을 삭제합니다.

@odigity 다음과 같은 구조를 테스트하면

// controller.js
const users = require('./usersModel.js');

module.exports.addUser = async ({ token, user }) => {
  // check token, or other logic
  return users.add(user);
};

// usersModel.js
const db = require('./db');

module.exports.add = async user => db('users').insert(user);

// db.js
module.exports = require('knex')({ /* config */});

나는 모든 함수가 트랜잭션을 실제 쿼리 빌더로 전달하기 위해 추가 인수 (예 trx )를 가져야합니다.
https://knexjs.org/#Builder -transacting

올바른 방법은 다음과 같아야한다고 생각합니다.

1. beforeEach trx를 만듭니다.
2. 어떻게 든 주입하십시오. 내 예에서 require('./db') sould return trx value.
3. 테스트를하십시오.
4. 'afterEach'에서 trx를 롤백합니다.

하지만 knex로 가능할까요?
코드가 다른 트랜잭션을 사용하면 어떻게됩니까?

또 다른 옵션 : 쿼리 실행을 시작하는 기능이있을 수 있습니다. 따라서 테스트 트랜잭션에서 강제 실행되도록 재정의 할 수 있습니다.

knex 코드를 읽은 후이 방법을 시도합니다.

test.beforeEach(async t => {
    // if we use new 0.17 knex api knex.transaction().then - we can not handle rollback error
    // so we need to do it in old way
    // and add empty .catch to prevent unhandled rejection
    t.context.trx = await new Promise(resolve => db.transaction(trx => resolve(trx)).catch(() => {}));
    t.context.oldRunner = db.client.runner;
    db.client.runner = function(builder) {
        return t.context.oldRunner.call(t.context.trx.client, builder);
    };
    t.context.oldRaw = db.raw;
    db.raw = function(...args) {
        return t.context.oldRaw.call(this, ...args).transacting(t.context.trx);
    };
});

test.afterEach(async t => {
    db.raw = t.context.oldRaw;
    db.client.runner = t.context.oldRunner;
    await t.context.trx.rollback();
});

그리고 그것은 약간 작동합니다. 그래서 .raw 및 .client.runner 메서드를 재정의합니다. .client.runner .then 는 쿼리 작성기를 db 는 knex 클라이언트 knex({ /* config */}) 입니다.

내가 이미 여기에서 설명했듯이 @Niklv ; 트랜잭션을 사용하여 테스트 데이터를 재설정하는 것은 일반적으로 나쁜 생각이며 반 패턴으로 간주 할 수도 있습니다. 그래서 knex 내부를 재정의합니다. 모든 테스트 또는 테스트 세트에서 db를 자르고 다시 채우는 것이 좋습니다. 테스트 데이터의 크기가 적당하면 수행하는 데 몇 밀리 초가 걸리지 않습니다.