"엄준일"과 함께하는 소프트웨어를 위한 플랫폼 이야기

데이터 무결성이란 일반적으로 '데이터 무결성'이라고 함은 큰 범주에서 데이터베이스에서 데이터의 정확성과 일관성을 보증하는 것을 의미한다. 이런 데이터의 무결성을 보증할 수 없는 경우 우리는 '데이터가 변질되었다' 라고 할 수 있다. 이는 데이터가 우리가 기대하던 원본과 달라졌음을 의미한다. 일반적으로 파일이나 네트워크에서 무결성을 검증하기 위해 체크섬(checksum) 을 이용하고, 프로그래밍 언어에서는 해시값(hashvalue) 를 이용한다. 이 둘은 데이터의 무결성을 보장하기 위해 단 하나의 비트(bit) 의 데이터라도 수정이 되면 전체 해시값에 영향을 주어 원본과 일치하지 않는 해시값이 된다. 이 원본 해시값을 사본 해시값과 비교하면 데이터의 무결성이 보장되는지 쉽게 알..

개요 Git을 이용하여 외부 모듈을 참조하려면 git submodule 명령을 이용해서 외부 모듈을 clone할 수 있다. git submodule 명령은 git clone과 달리 같은 작업 디렉토리(Working Directory)에 여러 모듈을 추가할 수 있는 장점이 있다. 샘플 코드 추가 (연습하기) 본 아티클에서 사용하는 샘플 코드는 필자가 개발한 Umc.Core의 의존성 주입(DI, Dependency Injection), 역전 제어(IoC, Inversion of Control), 관점 지향 프로그래밍(AOP, Aspect-Oriented Programming) 이다. submodule를 추가하고 제거하는 과정을 이해하기 쉽도록 Umc.Core 프로젝트를 사용한다. $ git clone htt..

최근 Git이나 Mercurial 과 같은 분산제어 방식의 소스 제어 제품을 무조건 맹신하고 찬양하거나 분산제어 방식보다 중앙집중형 소스제어 방식을 무조건 배척하는 현상이 일부 나타나고 있다. 리누스 토발즈(Linus Tovalds)와 같은 공산주의(Communism) 사상의 이상을 강조하는 철학이 담긴 Git은 GitHub.com을 통해 소스 코드를 공유함으로서 오픈 소스 진영에 매우 발전적인 기여를 하고 있음은 확실하다. 리누스 토발즈(Linus Tovalds)가 만든 것이라 그런지 훨씬 더 주목받고 있는 것 같다. 중앙집중 소스제어와 분산제어 소스제어 방식은 그 원칙과 근본적인 가치에 차이가 있는, 방법론으로 접근해야 할 것이다. 따라서 각 소스 제어의 방식마다 특징과 장단점이 있으며 ‘좋은 게 좋..

부하테스트 이야기, 테스트 데이터 분석 문제 풀어보세요. 부하테스트 이야기 부하 테스트는 테스트 분류 상 '비기능 테스트'에 속하는 매우 정교한 테스트 중의 하나다. 부하 테스트는 수치화된 데이터를 통해 성능 지표를 도출한다. 대부분 부하 테스트는 클라이언트 응용 프로그램보다 서버 응용 프로그램에 주로 사용한다. 웹 서버나 통신과 관련된 서버, 그리고 데이터베이스가 대표적이다. 일반적으로 테스트라고 하면 '성공/실패'가 매우 명확하다. 그리고 '성공/실패'라는 결과에 대해 객관적으로 판단할 수 있고, 특별한 경우가 아니고서 '성공/실패'를 재연할 수 있는 시나리오를 가지고 있다. 반면 부하 테스트는 '성공/실패'는 경험적으로 판단해야 하며, 성공인지 실패인지에 대해 다른 사람과 의견이 일치하지 않는 경우..

메뉴얼 테스트 vs 테스트 자동화 (1) 매뉴얼 테스트와 테스트 자동화. 정말 그 범위를 정하기도 힘들고, 잘 하기도 힘든 가장 기초적인 테스트 방법입니다. 아마도 대다수의 사람들이 알고 있는 테스트의 기본이기도 합니다. 메뉴얼 테스트(Manual Test)는 수동 테스트라는 의미로 테스터에 의해 직접 수행하여 테스트 결과를 기록하는 방식이며, 테스트 자동화(Automated Test)는 자동 테스트라는 의미로 프로그래밍이나 스크립트에 의해 자동으로 테스트를 수행하여 결과를 기록하는 방식입니다. 개발자라면 테스트 자동화를 최우선으로 여기지만, 사실은 매뉴얼 테스트의 영역이 갖는 테스트의 의미는 매우 비중이 높습니다. 많은 사람이 오해하는 것 중에 하나가 자동화 테스트가 정교하고 정확하다고 생각한다는 것입..

TDD vs 계약기반 테스트 단위 테스트를 어떻게 해야 잘 하나…? 단위 테스트를 어떻게 해야 잘 하는지는 사실 논란의 여지가 굉장히 많습니다. 왜냐하면 TDD를 해본 사람 vs 안해본 사람 TDD가 능숙한 사람 vs 능숙하지 않은 사람 개발 툴에서 TDD를 제공하는 환경 vs 제공하지 않는 환경 테스트 지식이 있는 사람 vs 없는 사람 … 어쨌든 목표는 동일합니다. 작성된 코드에 대한 테스트를 수행하는 것이죠. 일반적으로 테스트의 목표에 따라 테스트 방법이 달라질 수 있지만, 흔히 단위 테스트는 기능 범위에 한하여 테스트 코드를 작성하는 방법입니다. 어떻게 코드가 변경이 되든, 어떤 데이터소스 이든지 간에 성공해야 할 테스트는 반드시 성공하고, 실패해야 할 테스트는 반드시 실패해야만 기능이 올바르게 동..

테스트 가상화... 몇 해 전부터 클라우드(Cloud) 붐이 일어나면서 굉장히 다양한 클라우드 인프라와 서비스가 여러 벤더에 의해 발전해 왔습니다. 그 중 Microsoft 는 가상화 기술을 기반으로 플랫폼, 인프라 서비스 등이 결합하여 Azure 라는 훌륭한 클라우드 서비스 환경을 구축하였습니다. 이런 클라우드 서비스의 가능성은 가장 최하위 기반이 되는 가상화 기술이 바로 그것입니다. 필자는 처음에는 클라우드라는 것이 도대체 GREEN IT 를 마케팅 용어로 벗삼고, TOC 절감과 관리적인 요소들에 그저 불편한 심기를 내비쳤습니다. 왜냐하면 늘 그래왔듯이 거품이 빠지고, 걸음마 수준의 기술과 마케팅으로 수 많은 것들이 기억 속에서 사라진 것들이 더 많기 때문입니다. 다시 본론으로 돌아와서, 테스트 가상..

2010년 8월 28일, Visual Studio Camp #1 에서 발표한 "Enterprise Track : [2] 소프트웨어 품질 향상을 위한 다양한 테스트 기법 - 엄준일 ALM MVP" 세션을 들어주신 분 중에 어느 테스트 전문가를 만나 뵙게 되었습니다. 최근 테스트 공학과 테스트 프로세스에 푹 빠져있는 저에게 매우 단비와도 같은 분이시고, 특히 테스트 전문 도구인 Load Runner 제품을 실제로 사용하고 계신 분이셨습니다. (http://willstory.tistory.com/4) 제 세션의 내용과 현재 사용하고 계신 Load Runner 제품에 대해 경험적으로 비교를 해 주신 후기를 작성해 주셔서, 여러분들에게 도움이 될까 싶어 @will_story 님의 동의를 얻어 저희 팀 블로그에 게..

테스트 계획 테스트 계획은 테스트 작업을 시작하기 위한 가장 기초적인 명세서입니다. 테스트를 어떻게 진행하고 어떻게 결함을 발견할 것인지 계획을 갖고 테스트에 진입하는 것이죠. 테스트 계획 없이 테스트를 한다는 것은 아키텍처 없이 머리 속의 청사진으로 프로그램을 코드를 짜는 것과 마찬가지입니다. 그만큼 테스트 계획은 테스트에 있어서 첫 발을 내 딛는 중요한 작업입니다. 테스트 계획은 좋은 소프트웨어의 첫 걸음 아마 독자 여러분들 중에 개발 프로젝트를 한 두 번쯤 리딩(Leading) 해 보신 경험이 있다면 아실 겁니다. 좋은 설계과 좋은 계획만으로 좋은 소프트웨어가 나오는 것이 아니라는 것을…. 물론 좋은 소프트웨어를 위해 밑거름이 바로 계획입니다. 그리고 계획이 좋거나 나쁘다고 해서, 소프트웨어의 품질..

샘플 프로그램으로 시작해보자고!! 아주 간단한 Windows Forms 어플리케이션을 작성해 보았습니다. 실제로 실무에서는 이렇게 간단한 프로그램을 만드는 개발자도 없겠지만, 아주 간단한 것 부터 시작하여 테스트의 필요성과 테스터의 역할이 얼마나 중요한지 알 수 있는 시간이 되길 바랍니다. 아래의 윈폼 어플리케이션은 숫자A와 숫자B 를 더하여 결과를 보여주는 프로그램입니다. 아래와 같이 간단하게 디자인을 하였습니다. 소스 코드는 더할나위 없이 간단합니다. 특별한 설명은 하지 않겠습니다. 이 프로그램으로 1과 2 값을 입력하면 당연히 3이라는 결과가 출력되어야 합니다 아래와 같이 말이죠. 프로그램이 완벽하지요?? 정말일까요?? 특히 프로그램을 개발하는 개발자의 시각은 테스터와 매우 다릅니다. 일반적으로 개..

이전 글 [Software Development/Agile] - [ALM-Test] 왜 단위 테스트를 해야 하는가? [1] 이미 이전 포스트에서 얘기 했듯이, 똑같은 "단위 테스트"라는 단어를 가지고 개발자, 테스터, 고객은 각자 그 의미를 전혀 다르게 생각하고 있습니다. 이런 단어의 해석 조차 각자 틀린데, 애자일(Agility)하게 어떻게 소프트웨어를 만들 수 있을까요. 이미 "단위 테스트" 라는 작은 주제를 가지고 벌써부터 고객과 개발 조직간의 불화음이 발생합니다. 아니, 이미 개발 팀 내부에서부터 어디서 부터 시작해야 할지 어디둥절 할 수 있습니다. 그렇다면 과연 "단위 테스트" 가 결함의 발생을 줄이는 약이 될지, 팀 간의 커뮤니케이션 장애를 발생시키는 독이 될지, 그것은 아마 이 글을 읽는 독..

애자일(Agile) 프로그래밍 기법 등이 대중화 되면서, 특히 XP(eXtreme Programming) 에서는 단위 테스트의 코드를 먼저 작성하라고 합니다. 그것이 바로 TDD(Test Driven Development) 입니다.! 그 이유는 다들 아시다시피 간단합니다. 바로 코드를 작성할 때 설계부터 하라는 것입니다. 좀 직설적으로 얘기하자면, 생각 좀 하고 만들라는 것이죠. 생각 없이 만들 코드를 나중에 리팩토링(Refectoring) 할 바에는 처음부터 리팩토링 비용을 줄이고, 좀 더 세련된 디자인으로 코드를 작성하라는 의미입니다. 단위 테스트(Unit Test) 라는 의미에서도 사실 개발자와 테스터, 고객과는 굉장히 괴리감이 있는 단어이기도 합니다. "단위 테스트" 라는 똑같은 단어를 사용하지만..

목차 [Testing] TDD (Test-Driven Development)-테스트 주도 개발 [Testing] BDD (Behavior-Driven Development)–행위 주도 개발 [Testing] Moq.NET (T/B Driven Development)  Moq.NET Moq 는 "Mock-you" 또는 "Mock" 로 부른다고 합니다. Moq.NET 3.0 은 C# 3.0 과 .NET Framework 3.5 를 통해 Linq Expression Tree 와 Lambda Expression(람대 표현식) 으로 직관적이고 생산적이라고 합니다. 이전에 봤던 웹 사이트 로그인 사용자 스토리를 다시 봅시다. 단, 이 예제에서는 복잡성을 만족하는 항목을 삭제합니다. 웹 사이트의 로그인 사용자 스토..

목차 [Testing] TDD (Test-Driven Development)-테스트 주도 개발 [Testing] BDD (Behavior-Driven Development)–행위 주도 개발 [Testing] Moq.NET (T/B Driven Development)  그렇다면 BDD (Behavior-Driven Development) ! TDD 는 그렇다고 치고, 이제는 BDD(Behavior-Driven Development-행위 주도 개발) 가 왠말이냐 -_-; 저 또한 Moq 에 생소한 나머지 여기까지 추적하게 되었습니다. 모두가 TDD 가 좋은 줄은 압니다. 종속적인 기능이나 코드가 정상적임을 증명하고 점진적으로 테스트 코드를 만듦으로써 자연스럽게 세부 설계를 생각하게 할 수 있습니다. 나에게..

목차 [Testing] TDD (Test-Driven Development)-테스트 주도 개발 [Testing] BDD (Behavior-Driven Development)–행위 주도 개발 [Testing] Moq.NET (T/B Driven Development) 이번에 Moq.NET 3.0 버전이 릴리즈 되었습니다. Moq.NET 는 Mocking Object 를 통해 특정 테스트를 진행하고 훨씬 TDD 기반에 근접한 테스팅을 가능하게 합니다. 즉, Mocking Object 는 실제 클래스나 개발이 완료되지 않는 시점에서부터 테스트를 가능하도록 합니다. 그런데 필자는 Moq.NET 를 이해하는 과정에서 내가 알고 있던 것보다 더 깊은 배경이 있었다는 것을 알게 되었습니다. 예를 들어, TDD 외에 ..

Blueprints 는 새로운 개념의 Software Factory 입니다. 언제나 우리는 반복되는 작업과 그것을 수행하기 위한 새로운 기술, 그리고 좋은 패키지를 만들기 위한 디자인, 그리고 버그를 수정하기 위한 작업을 팩토리(Factory) 라는 개념의 트랜드된 기술입니다. 팩토리(Factory) 는 Web Service, Rich Internet Application(RIA), Service Facade 를 쉽게 제공할 수 있으며 그것은 특정 프로세스, 리소스, 가이드라인, 패턴, 템플릿, 라이브러리 등이 포함됩니다. Blueprints 의 팩토리는 소프트웨어 생산 공정(Software product line-SPL) 의 형태입니다. 일관된 공통적인 프로세스를 통해 패턴을 정하여 또는 공통적인 프로..