싱글턴을 사용하는 코드를 테스트하기는 어렵습니다. 일반적으로 테스트하려는 코드는 싱글턴 인스턴스와 강력하게 결합되어 있습니다. 싱글턴 객체가 종종 정적 이니셜라이저나 정적 메서드에서 생성되기 때문에 싱글턴 객체의 생성을 제어할 수 없습니다. 결과적으로 싱글턴 인스턴스의 동작을 목킹(mocking)할 수도 없습니다.

메서드의 입력값을 명확하게 식별할 수 없을 때 어떻게 제대로 테스트할 수 있을까요?

영화 아마데우스에서 오스트리아 황제는 모차르트의 음악에 “음표가 너무 많다”고 비판합니다. 하나의 기능을 테스트하는 데 “너무 많은” 테스트는 몇 개일까요?

스트룹 효과는 대략적으로 레이블(이 경우 단어)이 내용(색깔)과 같은 영역에 있고 의미가 충돌할 때, 레이블이 내용을 이해하는 능력에 방해가 된다는 것을 의미합니다.

Michael Feathers는 좋은 단위 테스트의 특징을 ‘빠르게 실행되고 문제 위치를 파악하는 데 도움이 된다’ 고 정의합니다. 코드에 데이터베이스 액세스, 다른 서버와의 통신, 시간 의존성 등이 있을 때는 이를 달성하기 어렵습니다.

invokeAll 은 ExecutorService 의 메서드로, 여러 제출된 작업을 동시에 시작합니다. ExecutorService 는 스레드 풀에서 플랫폼 스레드를 사용하여 제출된 작업을 실행합니다. 이 비싸고 리소스 집약적인 플랫폼 스레드를 사용하는 대신, 가상 스레드를 사용하여 ExecutorService 에 제출된 작업을 실행할 수도 있습니다. 이 글에서는 invokeAll 메서드를 가상 스레드 (virtual threads), 구조화된 동시성 (structured concurrency) 및 플랫폼 스레드 (platform threads) 와 함께 구현하는 모든 방법을 다룰 것입니다.

저희는 테스팅에 대한 열정을 전 세계에 전파하고, 여러분과 여러분의 회사에 이러한 중요한 트릭과 기술을 재미있고 쉽게 교육하는 방법을 제공하기 위해 이 비밀 병기를 전 세계와 공유하기로 결정했습니다.

Go(종종 Golang으로 불림)는 처음부터 동시성을 염두에 두고 설계되었습니다. 이 언어는 고루틴, 채널 및 강력한 동시성 모델을 도입하여 다른 많은 언어에서 발견되는 전통적인 접근 방식에 비해 동시성 프로그램을 더 간단하고 직관적으로 작성할 수 있게 했습니다.

이 기사는 Google Testing on the Toilet(TotT) 에피소드에서 각색되었습니다.

복잡하고 풍부한 웹 앱은 일반적으로 여러 서버가 각기 다른 작업을 수행하며 서로 통신하는 미로와 같습니다. 사용자 작업은 사용자로부터 데이터 저장소로, 그리고 다시 돌아오는 왕복 과정에서 이 서버 미로를 탐색합니다. Gmail과 Google+를 포함한 많은 Google 웹 앱이 이와 같습니다. 그렇다면 이러한 앱에 대한 종단 간 테스트는 어떻게 작성할까요?

이 글은 Google Testing on the Toilet (TotT) 에피소드에서 각색되었습니다.

훌륭한 표준 라이브러리와 패키징 시스템, 일등석 동시성 지원, 그리고 가독성에 대한 집중은 Golang 개발자들이 만족하는 특성 중 일부입니다.

… 스택 꼭대기에 서서 아래를 내려다보니, 그동안 제가 보아온 두 가지 유형 — 그리고 어쩌면 세 번째 유형 — 의 소프트웨어 엔지니어링에 대해 생각하게 되었습니다.

Java 23은 성능 및 개발자 생산성 향상 추세를 이어갑니다. 기본 타입을 지원하는 패턴 매칭을 개선하고, 더 안전한 메모리 관리를 위해 Scoped Values를 도입하며, 구조화된 API를 통해 동시성을 단순화합니다. Markdown 문서화는 개발자 경험을 개선하고, ZGC가 기본 컬렉터가 되어 더 나은 성능과 낮은 지연 시간을 보장합니다.

이 글에서는 제가 오래된 게임을 디컴파일하기 위해 AI를 사용한 개발 여정을 공유하고, 이 재미있는 분야에서의 개인적인 연구를 탐색해 보려고 합니다!

Cursor와 Claude Code는 시간을 투자할 만한 가치가 있는 옵션 중 일부입니다.

스펙을 브레인스토밍하고, 계획을 계획한 다음, LLM 코드 생성을 사용하여 실행합니다. 개별적인 루프. 그리고 마법