나는 최근 몇 달 간 hurl을 사용하기 시작함
테스트 스위트 모드와 개별 호출 모드를 모두 쓸 수 있다는 점이 아주 만족스러움
CI에서 HTTP 요청 테스트 스위트를 실행하는 데 사용함
설정 언어는 블록이 직관적이지 않고, 지원하는 assertion 관련 문서도 약간 부족하다고 느낌
전반적으로 도구 자체가 큰 가치를 제공함
POC 작업할 때 인터페이스 테스트를 시작했고, 이 방식이 LLM 기반 개발을 도울 수 있다는 사실을 알게 됨
테스트를 HTTP 메소드에 직접 작성하니, 프로젝트 진화 과정에서 테스트와 구현이 더 유연하게 분리됨
테스트 분리 덕분에 인터페이스와 구현 간 경계가 더 분명해짐
hurl을 도입하기 전엔 서비스 언어의 테스트 프레임워크로 테스트 코드를 작성했지만, hurl 기반 테스트로 '클라이언트 관점'을 엄격하게 지키게 됨
백도어 데이터 접근 같은 것 없이, 인터페이스, 테스트, 구현이 철저히 분리되어 안심할 수 있음
hurl의 개발자임
피드백 고마움
6~7년 전 첫 개발을 시작할 때는 JSON, 그다음에는 YAML 포맷에 도전했지만 점차 새로운 파일 포맷을 직접 만들기로 확신하게 됨
이게 사용자 입장에서 어색할 수 있다는 점 충분히 이해함
더 단순한 사례에 단순한 문법을 적용하려 노력했지만, 완벽하진 않을 수 있음
문서 관련해서 부족하거나 개선점이 있다면 적극적으로 의견을 받고 향상시키길 희망함
Hurl 정말 멋진 도구임
예전에 Python으로 작성된 웹 서비스를 Rust로 포팅했을 때 엄격한 public API 테스트가 큰 도움이 됨
언어에 독립적인 통합 테스트 환경 덕분에 API나 웹사이트는 그대로 두고, 백엔드만 교체해도 됨
Rust에서 Hurl을 쓸 때만의 특별한 이점 하나 더 있음
cargo test와 연동해서 hurl 라이브러리를 바로 쓸 수 있고, .hurl 파일을 그대로 재사용 가능
데모: https://github.com/perrygeo/axum-hurl-test
나는 Hurl을 2023년 9월부터 사용하기 시작함
Runscope를 통해 테스트 스위트를 돌렸었지만, 변경사항이 버전 관리 안 되는 게 너무 불편했음
기초 작업을 거쳐 Hurl로 전환했고, Runscope는 버림
이제 누가 언제 왜 무엇을 바꿨는지 한눈에 확인 가능해져서 만족 중임
Runscope에서 변경사항이 버전 관리 안 되는 점 정말 싫었음
우리 팀도 그 문제를 해결하려다 프로젝트가 속도를 잃었음
개념 자체는 좋다고 생각하지만 ‘왜 써야 하나’ 고민하게 됨
나는 Django에서 개발하는데, 프레임워크 내장 테스트 기능이 이미 굉장히 충실함
나만의 백엔드를 모르고 외부에서만 접근하는 도구 도입이 오히려 동기화 부담만 커질 것 같음
이상하면 디버거로 바로 뛰어드는 것도 못 하게 됨
테스트 코드와 백엔드 코드를 명확히 분리해야 한다는 논리도 있긴 하지만, 실질적으로는 관리 비용이 더 커짐
결국 네이티브 테스트 스위트도 돌려야 할 거라서, 외부 도구를 여러 개 병행하는 게 어색하게 느껴짐
단, API가 얼마나 범용적으로 동작하는지 검증하는 용도라면 쓸만할지도 모르겠음
왜 내 백엔드를 모르는 도구를 써서 동기화 수고만 늘려야 하냐는 질문에 나도 고민이 많았음
hurl은 써본 적 없지만, 언어와 무관하게 API를 테스트하는 도구들은 여러 번 썼고 직접 개발 중이기도 함
이런 도구들이 좋아 보이는 이유는
내부 구현을 몰라도 돼서 오히려 장점임
인풋-아웃풋만을 검증하는 구조 덕분에 내부 로직에 의존하지 않음
언어 독립적이라서 다른 팀과 공유할 때 (혹은 OpenAPI 사양을 대신해서) 문서처럼 쓸 수 있음
API 계약 자체를 테스트하므로 대규모 마이그레이션 때도 재사용 가능
예를 들면, Perl에서 Go로 public API를 옮길 때 기존 Perl API를 비-회귀 테스트로 삼고, 같은 테스트를 Go API에서 그대로 써서 신뢰도가 높아짐
개발자가 이런 테스트를 짜면 잠시 직접 API의 소비자 입장으로 관점을 바꿀 수 있어서, 더 품질 높은 테스트를 작성할 수 있었음
Postman 같은 제품의 대체제로 보면 됨
그냥 간단히 몇 개 http 요청 테스트하려고 electron 기반 무거운 창을 띄울 필요 없음
curl 스크립트와 Postman 사이 어딘가에 위치해서, 가벼움과 편의성이 동시에 필요한 사람에겐 최적임
우리는 ktor 웹 서버에서 spring boot 기반 코드(Java/Kotlin 스택)로 마이그레이션 할 때 Hurl을 활용함
서버 스택에 관계없이 명세 수준의 테스트 스위트를 운용할 수 있어서, 전환이 매우 수월했음
또, 도커 이미지를 프로덕션에 쓰는데, 너무 구현에 종속적인 도구 대신 Hurl을 써 통합 테스트를 매우 가볍고 독립적으로 할 수 있었음
그런 다음 output을 "expected.json" 파일과 1:1로 비교해서 통합 테스트 진행
이 파일들을 cURL과 bespoke bash 스크립트로 실행하고, jq로 결과를 비교해서 성공/실패를 콘솔에 로그 남김
Hurl로도 이런 식으로 IDE에서 예시 HTTP 요청과 JSON 파일 기반 기대 결과를 정의할 수 있는지 궁금함
그리고 Hurl로 폴더 내 여러 파일을 자동 실행할 수 있나 궁금함
Hurl은 HTTP 레벨 테스트 스위트를 예쁘게, 유지보수 쉽게 작성할 수 있다는 점에서 저평가되어 있음
이런 툴을 개발해줘서 고마움
Hurl이라는 이름 선정이 너무 만족스러움
개발자 센스에 감탄함
Hurl을 한동안 쓰다가 직접 기여하기도 함
"include" 기능을 제공할 가능성은 어떻게 되는지 궁금함
지속적으로 관리해줘서 고맙다는 인사
2년 뒤 Hurl의 비전과 미래는 어떻게 보고 있는지 궁금함
이 프로젝트에서 많은 영감을 얻어 직접 HTTP 테스트 도구를 설계함
우린 수백 개 테스트를 빠르게 병렬로 실행할 필요가 있었는데, Hurl이 마음에 든다면 Nap이라는 도구도 흥미로울 수 있음
설정(config) 문법이나 내용이 Hurl과 같은지, 어떤 점이 다른지 궁금함
차이점을 정리해서 보여주는 페이지가 있다면 알려주길 바람
흥미롭게 보임
나는 원래 Vscode-restclient를 오래 썼지만 스크립트 및 CLI 용도로 최근엔 httpyac으로 옮기고 있음
Hurl도 내가 원하는 요건에 맞는지 살펴볼 계획임
테스트 도구를 쓰면서 불편한 점 중 하나는 .http 파일에서 한 요청의 결과값을 다음 요청의 입력으로 참조하는 표준이 아직 없다는 것임
지금까지 써본 세 도구가 모두 방법이 다름
또 다른 파일 포맷을 만들어서 미안함!
이 문제를 조금이나마 줄일 방법으로 hurlfmt를 활용할 수 있음
hurlfmt는 Hurl 파일을 JSON으로 내보낼 수 있게 해줌
이 JSON 결과를 사용해 다른 도구와 상호 변환을 만들 수도 있음
마법처럼 완벽한 해결책은 아니지만 Hurl에서 다른 포맷으로 옮길 때 조금 도움이 될 수 있음
Visual Studio Code와 Visual Studio가 모두 .HTTP 파일 지원하지만, 서로 호환 안 됨
Conway's Law가 실전에서 재현된 사례라며 흥미롭게 보임
Hacker News 의견
나는 최근 몇 달 간 hurl을 사용하기 시작함
테스트 스위트 모드와 개별 호출 모드를 모두 쓸 수 있다는 점이 아주 만족스러움
CI에서 HTTP 요청 테스트 스위트를 실행하는 데 사용함
설정 언어는 블록이 직관적이지 않고, 지원하는 assertion 관련 문서도 약간 부족하다고 느낌
전반적으로 도구 자체가 큰 가치를 제공함
POC 작업할 때 인터페이스 테스트를 시작했고, 이 방식이 LLM 기반 개발을 도울 수 있다는 사실을 알게 됨
테스트를 HTTP 메소드에 직접 작성하니, 프로젝트 진화 과정에서 테스트와 구현이 더 유연하게 분리됨
테스트 분리 덕분에 인터페이스와 구현 간 경계가 더 분명해짐
hurl을 도입하기 전엔 서비스 언어의 테스트 프레임워크로 테스트 코드를 작성했지만, hurl 기반 테스트로 '클라이언트 관점'을 엄격하게 지키게 됨
백도어 데이터 접근 같은 것 없이, 인터페이스, 테스트, 구현이 철저히 분리되어 안심할 수 있음
피드백 고마움
6~7년 전 첫 개발을 시작할 때는 JSON, 그다음에는 YAML 포맷에 도전했지만 점차 새로운 파일 포맷을 직접 만들기로 확신하게 됨
이게 사용자 입장에서 어색할 수 있다는 점 충분히 이해함
더 단순한 사례에 단순한 문법을 적용하려 노력했지만, 완벽하진 않을 수 있음
문서 관련해서 부족하거나 개선점이 있다면 적극적으로 의견을 받고 향상시키길 희망함
Hurl 정말 멋진 도구임
예전에 Python으로 작성된 웹 서비스를 Rust로 포팅했을 때 엄격한 public API 테스트가 큰 도움이 됨
언어에 독립적인 통합 테스트 환경 덕분에 API나 웹사이트는 그대로 두고, 백엔드만 교체해도 됨
Rust에서 Hurl을 쓸 때만의 특별한 이점 하나 더 있음
cargo test와 연동해서 hurl 라이브러리를 바로 쓸 수 있고, .hurl 파일을 그대로 재사용 가능
데모: https://github.com/perrygeo/axum-hurl-test
나는 Hurl을 2023년 9월부터 사용하기 시작함
Runscope를 통해 테스트 스위트를 돌렸었지만, 변경사항이 버전 관리 안 되는 게 너무 불편했음
기초 작업을 거쳐 Hurl로 전환했고, Runscope는 버림
이제 누가 언제 왜 무엇을 바꿨는지 한눈에 확인 가능해져서 만족 중임
우리 팀도 그 문제를 해결하려다 프로젝트가 속도를 잃었음
개념 자체는 좋다고 생각하지만 ‘왜 써야 하나’ 고민하게 됨
나는 Django에서 개발하는데, 프레임워크 내장 테스트 기능이 이미 굉장히 충실함
나만의 백엔드를 모르고 외부에서만 접근하는 도구 도입이 오히려 동기화 부담만 커질 것 같음
이상하면 디버거로 바로 뛰어드는 것도 못 하게 됨
테스트 코드와 백엔드 코드를 명확히 분리해야 한다는 논리도 있긴 하지만, 실질적으로는 관리 비용이 더 커짐
결국 네이티브 테스트 스위트도 돌려야 할 거라서, 외부 도구를 여러 개 병행하는 게 어색하게 느껴짐
단, API가 얼마나 범용적으로 동작하는지 검증하는 용도라면 쓸만할지도 모르겠음
왜 내 백엔드를 모르는 도구를 써서 동기화 수고만 늘려야 하냐는 질문에 나도 고민이 많았음
hurl은 써본 적 없지만, 언어와 무관하게 API를 테스트하는 도구들은 여러 번 썼고 직접 개발 중이기도 함
이런 도구들이 좋아 보이는 이유는
인풋-아웃풋만을 검증하는 구조 덕분에 내부 로직에 의존하지 않음
예를 들면, Perl에서 Go로 public API를 옮길 때 기존 Perl API를 비-회귀 테스트로 삼고, 같은 테스트를 Go API에서 그대로 써서 신뢰도가 높아짐
Postman 같은 제품의 대체제로 보면 됨
그냥 간단히 몇 개 http 요청 테스트하려고 electron 기반 무거운 창을 띄울 필요 없음
curl 스크립트와 Postman 사이 어딘가에 위치해서, 가벼움과 편의성이 동시에 필요한 사람에겐 최적임
우리는 ktor 웹 서버에서 spring boot 기반 코드(Java/Kotlin 스택)로 마이그레이션 할 때 Hurl을 활용함
서버 스택에 관계없이 명세 수준의 테스트 스위트를 운용할 수 있어서, 전환이 매우 수월했음
또, 도커 이미지를 프로덕션에 쓰는데, 너무 구현에 종속적인 도구 대신 Hurl을 써 통합 테스트를 매우 가볍고 독립적으로 할 수 있었음
샘플 섹션(https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples)이 도구의 장점을 5분만에 파악하고 싶은 사람, 즉 미리 판단하는 경향이 있는 사람에게 매우 설득력 있게 느껴짐
나도 그 부류일 때가 종종 있는데, 정말 인상적임
Hurl의 관리자임
질문이나 피드백 언제든 환영함
나를 포함해 주변 개발자들이 많이 쓰는 패턴인데, VS Code나 IDEA의 IDE 확장으로 실행 가능한 ".http" 파일로 테스트를 씀
예시 포맷은
그런 다음 output을 "expected.json" 파일과 1:1로 비교해서 통합 테스트 진행
이 파일들을 cURL과 bespoke bash 스크립트로 실행하고, jq로 결과를 비교해서 성공/실패를 콘솔에 로그 남김
Hurl로도 이런 식으로 IDE에서 예시 HTTP 요청과 JSON 파일 기반 기대 결과를 정의할 수 있는지 궁금함
그리고 Hurl로 폴더 내 여러 파일을 자동 실행할 수 있나 궁금함
Hurl은 HTTP 레벨 테스트 스위트를 예쁘게, 유지보수 쉽게 작성할 수 있다는 점에서 저평가되어 있음
이런 툴을 개발해줘서 고마움
Hurl이라는 이름 선정이 너무 만족스러움
개발자 센스에 감탄함
Hurl을 한동안 쓰다가 직접 기여하기도 함
"include" 기능을 제공할 가능성은 어떻게 되는지 궁금함
지속적으로 관리해줘서 고맙다는 인사
2년 뒤 Hurl의 비전과 미래는 어떻게 보고 있는지 궁금함
이 프로젝트에서 많은 영감을 얻어 직접 HTTP 테스트 도구를 설계함
우린 수백 개 테스트를 빠르게 병렬로 실행할 필요가 있었는데, Hurl이 마음에 든다면 Nap이라는 도구도 흥미로울 수 있음
차이점을 정리해서 보여주는 페이지가 있다면 알려주길 바람
흥미롭게 보임
나는 원래 Vscode-restclient를 오래 썼지만 스크립트 및 CLI 용도로 최근엔 httpyac으로 옮기고 있음
Hurl도 내가 원하는 요건에 맞는지 살펴볼 계획임
테스트 도구를 쓰면서 불편한 점 중 하나는
.http파일에서 한 요청의 결과값을 다음 요청의 입력으로 참조하는 표준이 아직 없다는 것임지금까지 써본 세 도구가 모두 방법이 다름
hurl은 [Captures]
Vscode-restclient는 변수 선언에서 요청 이름을 참조
httpyac은 @ref 구문
각각의 구문이 달라서, 한 도구용으로 작성하면 다른 곳에선 깨짐
관련 참고 링크
hurl capture 문서
Vscode-restclient
httpyac ref 문서
또 다른 파일 포맷을 만들어서 미안함!
이 문제를 조금이나마 줄일 방법으로
hurlfmt를 활용할 수 있음hurlfmt는 Hurl 파일을 JSON으로 내보낼 수 있게 해줌
이 JSON 결과를 사용해 다른 도구와 상호 변환을 만들 수도 있음
마법처럼 완벽한 해결책은 아니지만 Hurl에서 다른 포맷으로 옮길 때 조금 도움이 될 수 있음
Visual Studio Code와 Visual Studio가 모두 .HTTP 파일 지원하지만, 서로 호환 안 됨
Conway's Law가 실전에서 재현된 사례라며 흥미롭게 보임
약간 유사해 보임
https://marketplace.visualstudio.com/items?itemName=humao.rest-client
이 VS Code 확장은 HTTP 관련 테스팅에 매우 강력함
에디터 독립적으로 쓸 수 있다는 점이 정말 큰 차이점임
IntelliJ도 유사한 기능 있음
https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html
나도 Hurl을 써봤고 꽤 괜찮다고 느낌
하지만 최근엔 .http 방식을 더 선호하게 됨
IntelliJ엔 내장돼 있고, 위에 링크된 플러그인도 있고, CLI에선 httpYac도 써봄
벤더 락인도 없고, 소스 컨트롤이나 복사&붙여넣기로 공유하기도 매우 쉬움
JVM에서 나는 Karate로 통합 테스트를 진행함
https://github.com/karatelabs/karate
JavaScript를 임의로 포함할 수 있기 때문에, 요청/검증을 유연하게 작성할 수 있음