테스트 적용

InfoQ 홈페이지 뉴스 클라우드에 테스트 주도 개발 적용

이 항목은 일본어로 표시됩니다.

2023년 5월 25일 4분 분량의 읽기

~에 의해

벤 린더스

클라우드에서는 애플리케이션 개발이 그에 수반되는 인프라를 통해 엔드 투 엔드로 처리될 수 있습니다. 이를 통해 전체 애플리케이션에서 TDD(테스트 중심 개발) 및 리팩토링을 사용할 수 있어 유지 관리 비용을 절감할 수 있습니다.

Michal Svoboda는 XP 2023에서 클라우드 앱의 테스트 중심 개발에 대해 강연할 예정입니다. 이 컨퍼런스는 네덜란드 암스테르담에서 6월 13~16일에 개최됩니다.

클라우드 앱의 경우 애플리케이션을 하나의 일관된 코드 조각으로 수반되는 인프라와 함께 개발하고 배포할 수 있습니다. Svoboda에 따르면 "인프라"를 별도의 요소로 제거하면 클라우드 리소스를 포함한 전체 앱의 범위에 TDD 및 리팩토링과 같은 민첩한 엔지니어링 기술을 적용할 수 있습니다.

클라우드의 대기 시간과 비동기 특성이 문제가 될 수 있습니다. 리소스가 프로비저닝되거나 시간 초과가 경과할 때까지 기다리면 빠른 TDD 주기가 방해됩니다. Svoboda는 증분 업데이트 모델로 전환할 것을 제안합니다. 즉, 각 테스트가 끝날 때 리소스를 파괴하지 않고 통합할 때만 깔끔하게 배포하는 것입니다.

테스트 속도 향상 기술은 TDD 트릭 백에서 추출되었습니다. 상태 기반 테스트를 전술적으로 사용하거나 코드의 수정된 부분만 테스트하는 것이 몇 가지 예입니다. 테스트의 장애물은 전체 개발 주기에 유용한 피드백을 제공한다는 점을 기억하는 것이 좋습니다. 이 피드백을 통해 우리는 아키텍처와 절차 선택을 신중하게 검토하게 되었습니다.

Svoboda에 따르면 TDD는 소프트웨어 TCO의 주요 부분인 앱 유지 관리 비용을 절감합니다. TDD를 사용하면 몇 년이 지난 후에도 자체 코드이든 클라우드 리소스 사용이든 어디에서나 쉽게 기능을 추가하거나 리팩터링할 수 있습니다.

InfoQ는 TTD를 사용한 클라우드 개발에 관해 Michal Svoboda를 인터뷰했습니다.

InfoQ: 클라우드는 인프라 프로비저닝 방식에 어떤 영향을 미쳤습니까?

미칼 스보보다 : API를 통해 완전 자동화된 방식으로 클라우드 리소스를 생성하고 폐기할 수 있습니다. (엄밀히 말하면 이것은 단순한 클라우드가 아닙니다. 클라우드 제공업체는 이 기능에 대한 접근성을 극도로 높였습니다.) 애플리케이션과 독립적으로 존재하는 서버 및 네트워크와 같은 "인프라"에 대해 생각할 필요가 없습니다. "인프라"에는 더 이상 특별한 접근 방식이 필요하지 않습니다.

클라우드는 클래식 인프라 위에 스토리지, 기능, 스트림 등 단일 전문 서비스를 제공합니다. 많은 클라우드 앱은 클라우드에서만 실행되는 것이 아니라 클라우드로 구성됩니다.

InfoQ: 클라우드 애플리케이션에 대한 테스트 중심 개발을 어떻게 수행합니까?

스보보다 : 클라우드 앱의 TDD는 다른 앱의 TDD와 유사합니다. 메모리에 객체를 생성하기 위해 생성자와 함수를 호출하는 대신 API를 호출하여 클라우드에 리소스를 생성합니다. 스트림 리소스에 대한 "정렬, 실행, 주장" 테스트는 아래 의사 코드에 설명되어 있습니다.

[스트림을 쓰고 읽을 수 있는지 테스트]

이것은 매우 간단한 기능 테스트입니다. 상태 기반 테스트는 리소스의 "구성을 쿼리"하는 API 호출을 사용하여 수행할 수 있습니다. 동일한 원리를 사용하여 보다 복잡한 리소스 설정을 테스트할 수 있습니다.

TDD에 따라 테스트를 먼저 작성하고, 실패하고, 구현을 따르도록 합니다. 중요한 것은 우리가 피드백을 듣고 테스트의 어려움이 개발을 주도하도록 한다는 것입니다. 우리의 기술, 아키텍처 및 절차 선택은 테스트 용이성을 기반으로 합니다.

InfoQ: 어떤 어려움에 직면했고 어떻게 해결했습니까?

스보보다 : 사용 가능한 툴링이 문제였습니다. 이 클라우드 기반 TDD 접근 방식이 제대로 작동하려면 리소스 배포 코드가 선택한 프로그래밍 언어에서 일류 시민이어야 합니다. 최신 도구는 "클라우드 Makefile" 방식으로 해당 언어로 모델에 대한 명령줄 인터페이스를 제공합니다. 이러한 도구는 "별도의 인프라" 패러다임을 따르기 때문에 통신이 번거로울 수 있습니다. 이는 개발 초기에도 훌륭한 피드백이었으며 도구 및 공급자 결정에 영향을 미쳤습니다.