프로그래밍 언어는 우리에게 많은 표현력을 제공합니다. 연산자와 조건문 같은 개념들은 광범위한 입력을 처리하는 프로그램을 작성할 수 있게 해주는 중요한 도구입니다. 하지만 이러한 유연성은 복잡성 증가라는 대가를 치르게 하여, 우리 프로그램을 이해하기 어렵게 만듭니다.

이 글에서는 LLM을 활용한 Vibe-Coding 시대에 Go 언어가 가지는 장점들을 알아봅니다.

서버가 과부하되었다는 소식이 들려왔습니다. 사람들은 왜 Gemini CLI에 그렇게 열광하는 걸까요? 우리는 이미 웹과 데스크톱에서 사용할 수 있는 ChatGPT와 Claude, 그리고 Cursor와 Windsurf 같은 코딩 AI 도구, 심지어 Lovable과 V0 같은 바이브 코딩 도구까지 가지고 있습니다. 터미널 기반의 새로운 CLI 기반 AI가 이 시장에 어떤 영향을 미칠 수 있을까요?

테스트는 목적을 위한 수단입니다: 프로젝트의 주요 위험을 줄이고, 가장 큰 효과를 얻기 위함입니다. 이 효과는 항상 표준 관행에 따라 작성하는 테스트에서 나오지 않을 수 있으며, 심지어 테스트에서 전혀 나오지 않을 수도 있습니다.

개별 단위 테스트를 작성하든 제품의 전체 테스트 프로세스를 설계하든, 테스트가 코드의 버그를 얼마나 효과적으로 감지하고 보고하는지 다시 한번 생각해보는 것이 중요합니다. 효과적이려면 모든 테스트가 극대화하려고 노력해야 하는 세 가지 중요한 품질이 있습니다.

메서드를 작성한 후 메서드가 수행하는 모든 작업을 확인하는 테스트를 하나만 작성하기 쉽습니다. 그러나 테스트와 public 메서드가 1:1 관계를 가져야 한다고 생각하는 것은 해로울 수 있습니다. 우리가 정말로 테스트하고 싶은 것은 동작이며, 단일 메서드가 여러 동작을 나타낼 수 있고, 단일 동작이 때로는 여러 메서드에 걸쳐 있을 수도 있습니다.

단위 테스트는 코드의 정확성을 확인하는 중요한 도구입니다. 그러나 좋은 테스트를 작성하는 것은 단순히 정확성을 확인하는 것 이상입니다. 좋은 단위 테스트는 읽기 쉽고 유지 보수 가능하도록 여러 다른 속성을 보여야 합니다.

오늘날, 기본적인 코딩 기술은 더 많은 AI 토큰을 구매함으로써 채용될 수 있다. 당신은 그것을 기반으로 고용해서는 안 된다.

단위 테스트가 테스트 중인 코드가 제대로 작동하는지 확인하는 방법은 일반적으로 두 가지가 있습니다: 상태 테스트 또는 상호작용 테스트. 이들의 차이점은 무엇일까요?

단위 테스트가 테스트 중인 코드가 제대로 작동하는지 확인하는 방법은 일반적으로 두 가지가 있습니다: 상태 테스트 또는 상호작용 테스트. 이들의 차이점은 무엇일까요?

최근의 모든 스포츠 약물 스캔들로 인해 요즘 좋은 롤 모델을 찾기가 어렵습니다. 하지만 롤 모델이 도메인 모델(비즈니스 엔티티의 객체 모델)이라면 MVP가 되기 위해 속임수를 쓸 필요가 없습니다. Model-View-Presenter를 사용하세요!

부족함에 대한 지속적인 느낌을 억누르기 위해, 당신은 공학 분야의 진정한 통과 의례인 자신만의 행성 파괴 광선총을 만드는 데 시간을 들였습니다. 축하합니다. 그리고 당신은 매우 자랑스러워했지만, 그 다음 주말에 이워크 해설이 포함된 한정판 스타워즈 삼부작을 구매하여 데스스타가 알데라안을 파괴하는 것을 보고 잘못된 결정을 내렸다는 것을 깨달았습니다. 당신의 행성 파괴 광선총은 파란색 레이저를 가지고 있지만, 녹색 레이저가 훨씬 더 멋있어 보입니다. 하지만 라디오 셕에 가서 기존의 파괴 광선총에 끼울 수 있는 녹색 레이저를 사는 것은 간단한 문제가 아닙니다. 녹색 레이저를 가지려면 처음부터 다른 행성 파괴 광선총을 만들어야 할 것입니다. 두 개의 파괴 광선총을 소유하는 것이 하나보다 이웃들의 질투심을 더 자극할 것이므로 당신에게는 괜찮습니다.

당신은 페어 프로그래밍을 하고 있고, 많은 뛰어난 사람들이 그렇듯이 소리 내어 말하고 있습니다. "목을 만들고, 주입하고, 테스트를 다시 실행할 거야. 통과해야 하는데… 젠장!" 당신의 파트너는 예외 "ConnectionFactory not initialized"를 발견합니다. "뭐?" 그녀는 말합니다. "뭔가가 데이터베이스를 사용하고 있어? 젠장, 이건 작은 테스트여야 했는데."

테스트 환경에서 사용하기 너무 어렵거나 느린 것에 의존하는 코드를 테스트하고 싶을 때는, 의존성 대신 테스트 더블을 사용하세요.

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

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

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

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

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

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