- CppUnit . . . . 79 matches
C++ 에서 UnitTest를 하기 위한 UnitTestFramework. http://sourceforge.net/projects/cppunit/ 에서 다운 받을 수 있다.
C++ 의 또다른 형태의 UnitTestFramework 로 CxxTest 가 있다.
* Library 화일 생성 : {{{~cpp ...cppunitexamplesexamples.dsw }}} 을 연뒤 {{{~cpp WorkSpace }}}의 {{{~cpp FileView }}}에서 {{{~cpp CppUnitTestApp files }}} 에 Set as Active Project로 맞춰준다.(기본값으로 되어 있다.) 그리고 컴파일 해주면 lib 폴더에 library 화일들이 생성될 것이다.
http://zeropage.org/~reset/zb/data/TestHierarchy.jpg
http://zeropage.org/~reset/zb/data/TestRunner.jpg
* Project Setting - Link - General - object/library 에 cppunitd.lib, testrunnerd.lib 를 추가해준다.
* 해당 프로젝트가 있는 곳의 debug 등의 디렉토리에 해당 lib 디렉토리에 있는 testrunnerd.dll 을 복사해준다. 이는 Project Setting - Post-Build-step 의 Post-build-command 에 다음을 추가해주면 컴파일 할때마다 dll 화일을 자동으로 복사해준다.
copy c:cppunitlibtestrunnerd.dll .
* app 클래스에 다음과 같은 runner 실행을 위한 코드를 추가한다. 다음 코드를 추가함으로써 프로그램 실행시에 GUI Test Runner 가 실행된다.
#include <msvc6/testrunner/testrunner.h>
#include <cppunit/extensions/testfactoryregistry.h>
TestRunner runner;
runner.addTest ( CppUnit::TestFactoryRegistry::getRegistry().makeTest() );
= UnitTest TestCase의 작성 =
Test Case 가 될 Class는 {{{~cpp CppUnit::TestCase }}} 를 상속받는다.
== ExampleTestCase.h ==
#ifndef CPP_UNIT_EXAMPLETESTCASE_H
#define CPP_UNIT_EXAMPLETESTCASE_H
#include <cppunit/TestCase.h>
class ExampleTestCase : public CppUnit::TestCase
- PyUnit . . . . 79 matches
=== Python Unit Testing Framework PyUnit 에 대해서 ===
* PyUnit는 Python 에 기본적으로 포함되어있는 UnitTest Framework library이다. 하지만, UnitTest작성에 대한 기본적인 개념들을 쉽게 담고 있다고 생각하여 공부중. (솔직히 C++로 UnitTest할 엄두 안나서. --; Python으로 먼저 프로토타입이 되는 부분을 작성하고 다른 언어로 포팅하는 식으로 할까 생각중)
* http://junit.org - Java Unit Test Framework 모듈.
=== TestCase ===
unit testing 의 가장 기본적인 코드 블록 단위. 셋팅과 모듈이 제대로 돌아가는지를 체크하기 위한 하나의 시나리오가 된다.
PyUnit에서는 TestCase는 unittest모듈의 TestCase 클래스로서 표현된다.testcase 클래스를 만들려면 unittest.TestCase를 상속받아서 만들면 된다.
=== 간단한 testcase 의 제작. 'failure', 'error' ===
가장 간단한 방법은 runTest 메소드를 오버라이딩 하는 것이다.
import unittest
class DefaultWidgetSizeTestCase(unittest.TestCase):
def runTest(self):
테스팅을 하기 위해 Python의 assert 구문을 사용한다. testcase가 실행될 때 assertion을 실행하면 AssertionError 가 일어나고, testing framework는 이 testcase를 'failure' 했다고 정의할 것이다. 'assert' 를 명시적으로 써놓지 않은 부분에서의 예외가 발생한 것들은 testing framework 에서는 'errors'로 간주한다.
testcase를 실행하는 방법은 후에 설명할 것이다. testcase 클래스를 생성하기 위해 우리는 생성자에 아무 인자 없이 호출해주면 된다.
testCase = DefaultWidgetSizeTestCase ()
만일 testcase가 많아지면 그들의 set-up 코드들도 중복될 것이다. 매번 Widget 클래스를 테스트하기 위해 클래스들마다 widget 인스턴스를 만드는 것은 명백한 중복이다.
다행스럽게도 우리는 setUp 라는, testing framework가 테스팅을 할때 자동으로 호출해주는 메소드를 구현함으로서 해결할 수 있다.
import unittest
class SimpleWidgetTestCase(unittest.TestCase):
class DefaultWidgetSizeTestCase(SimpleWidgetTestCase):
def runTest(self):
- GuiTestingWithMfc . . . . 65 matches
CppUnit 을 이용한 MFC 에서의 GuiTesting (시도중. 결과는?)
http://zeropage.org/pub/GuiTesting/GuiTest1.gif
#include "GuiTestingOne.h"
#include "GuiTestingOneDlg.h"
#include "cppunit\ui\mfc\TestRunner.h"
#include "GuiTestCase.h"
BEGIN_MESSAGE_MAP(CGuiTestingOneApp, CWinApp)
//{{AFX_MSG_MAP(CGuiTestingOneApp)
CGuiTestingOneApp::CGuiTestingOneApp()
CGuiTestingOneApp theApp;
BOOL CGuiTestingOneApp::InitInstance()
CppUnit::MfcUi::TestRunner runner;
runner.addTest (GuiTestCase::suite());
/* --- Test Runner 만 실행되도록, 다이얼로그 띄우는 부분을 일단 막아둔다. 마지막에 실행할때 이 부분의 주석처리 된 부분을 풀어주면 된다.
CGuiTestingOneDlg dlg;
=== 2. Test Case 의 작성 ===
|| test1One || 연습겸 Assert Equals. 10 == 10 ||
|| test2GuiOne || 버튼이 눌러졌을 경우에 CGuiTestingOneDlg::m_bFlag 가 true 상태가 된다. ||
#include <cppunit/TestCase.h>
#include "GuiTestingOneDlg.h" // import GuiTestingOneDlg
- ProjectPrometheus/Journey . . . . 61 matches
* TestCase 통과 위주 ZeroPageServer 에서 TestCase 돌려봄
* Test 깨진 것 마저 수정. 테스트들 추가.
* UnitTest 들이 드디어 다시 녹색바. 그리고 서블릿에 있던 로직 부분을 Extract, 테스트들을 붙여줌.
* Test 마저 고치는 중, 내가 당연하다고 생각되었던 Test 가 깨진 문제 분석이 실제로 틀렸음을 알게 되었다. 상민이 덕택에 의외로 30분 내로 간단히 해결되었다. 오랜만에 AcceptanceTest 포함 80여개 테스트가 녹색불을 켜게 되었다.
* 서블릿 레이어부분에 대해서 Controller 에 Logic 이 붙는 경우 어떻게 Test 를 붙일까. (FacadePattern 을 생각하고, 웹 Tier 를 따로 분리하는 생각을 해보게 된다.) --["1002"]
* Test 깨진 것 수정하기.
Test 들이 있으면 확실히 좋은점은, 깨진 테스트들이 To Do List 가 된다는 점이다. 복구순서는? 깨진 테스트들중 가장 쉬워보이는 것이나, 그 문제를 확실하게 파악했다고 자부하는 테스트들을 먼저 잡고 나가면 된다.
* 근데, 해놓고 나서 커밋할 생각이.. 좀 안나긴 하다. 한편으로는 Test 들을 통과하니까 둘이 서로 정한 의도대로 한 것이니 상관없다는 생각. 하지만, 한편으로는 'Pair 로 한 것이 아닌데..' 하는 생각. 그냥 Spike 버전 정도로 생각해둘까나.
* 도서관 UI 변경과 관련, Test 깨진것 수정하기
다행히 모듈화가 잘 되어있었고, Test 들이 있었기에 ["neocoin"] 과 ["1002"] 는 주로 깨진 테스트들을 바로잡기로 했다. 일단 도서관들의 HTML 을 얻고, Local HTML 문서에 대해 데이터들을 잘 추출해내는지에 대한 테스트를 먼저 복구했다.
속좁은 ["1002"] 이 상민쓰에게 신경질 부리던날로 기억 -_-; 일종의 Test 에 대한 압박을 받아서이긴 한데, 처음에는 'Model, Logic' 부분에 대해서만 Test 정도 붙이면 되겠지 라고 생각했는데, Servlet 으로 작성한 Controller 부분이 커지면서, 각각 Command 에 해당하는 (service 라고 이름지었음) 부분에 대해 로직이 붙었기 때문이다. 근데, Servlet 이여서 테스트를 못붙이고, 작업은 작업대로 진행되는데 테스트 붙일 방법을 생각하지 못하는데, 잘 진행되어간다고 보이는 작업 발묶는것 같아서 이야기 못하고 꿍해있다는.
(그래서 수요일날에는 프로그램 작성전 Menual Test 방법을 먼저 생각해두고, 프로그래밍 작성을 하는 식으로 접근함)
* 대안을 생각중인데, 일종의 Facade 를 만들고, Controller 의 각 service 들은 Facade 만 이용하는 식으로 작성하면 어떨까. 그렇게 한다면 Facade 에 대해서 Test Code 를 작성할 수 있으리라 생각. 또는, Servlet 부분에 대해서는 AcceptanceTest 의 관점으로 접근하는 것을 생각. 또는, cactus 에 대해서 알아봐야 하려나.. --["1002"]
어제 마지막 고민이 지하철을 타고가면서 해결되었다. 그리고 오늘 와서 생각대로 적용하니 이후 Test들에서는 아무런 문제가 발생하지 않아서 안도의 한숨을 내쉰다. 시스템들이 Test를 통과하자, 가장 큰 문제로 발생된 것이 Test의 작성과 확인이었다. 책 4권과 사용자 3명.. 정말 머리에서 피시식 연기가 나는 느낌을 받는다. 그나마 Pair이기에 한명이 코드를 보면서 생각하고, 한명은 종이를 보면서 생각하면서 동기화를 시키니 다행이지, 혼자였다면 후유.. 문뜩 온라인 게임들이 굉장히 긴 시간동안 베타 테스트를 하는 것이 이해가 간다. --["상민"]
DB 쯤 되고 나니, Test 들의 보폭을 줄이는게 힘들어지는것 같다. (그리고..; 사람들이 잘 안줄이려고 하는것 같다;) TDD 가 좀 더 활성화되러면 학교 컴퓨터들이 더 빨라져야 한다고 개인적으로 생각중 -_-;
* {{{~cpp UserTest}}}구현
* {{{~cpp RecommenderTest}}} 의 테스트 수행중
* AcceptanceTest login , view page 테스트 추가
Spike Solution으로 만들어 두었던 것들이, 실제로 프로그래밍 소스로 전환되고 있는 과정 중이다. 이제 User내의 Spike Solution관련 코드들이 사라지면 Spike Solution의 Test들도 다 깨지면서 사라 질것이다. 내일이면 DB와의 연동이 마무리 되고, 웹에 인터페이스 노출이 이루어 질것 같다. 그렇게 되면 커다란 줄기는 완성되는 것이다. 역시나 감회가 새롭다. Acceptance Test에 관련한 코드들을 내가 너무 모르고 있다. 그쪽 코드를 보고 이해 해야 불안하고 들뜬 마음을 안정 시킬수 있을것 같다. 나는 즐거운거 맞는 걸까? 학교 더 일찍오면 확실히 즐거울꺼 같다. ;; --["상민"]
어차피 AcceptanceTest 관련 코드의 경우 Server 프로그램과 독립적으로 돌아가기에 그리 걱정하지 않아도 상관없을듯. 소스는 CVS에 올려놓고 있으니 시간있을때 확인하셔도 좋을듯. --["1002"]
- ScheduledWalk/석천 . . . . 61 matches
Spec 과 Test Case 는 ["RandomWalk2"] 에 있습니다.
StructuredProgramming 기법으로 StepwiseRefinement 하였습니다. 문제를 TopDown 스타일로 계속 재정의하여 뼈대를 만든 다음, Depth First (트리에서 깊이 우선) 로 가장 작은 모듈들을 먼저 하나하나 구현해 나갔습니다. 중반부터는 UnitTest 코드를 삽입하기를 시도, 중후반부터는 UnitTest Code를 먼저 만들고 프로그램 코드를 나중에 작성하였습니다.
1. 순차적으로 - 왼쪽 -> 오른쪽 순서로. 실행 순서에 따라 구현한다. (실행 순서와 상관없이 독립적으로 따로 생각하여 구현할 수 있습니다. 이는 UnitTest 참조)
IntPair testReceiver;
testReceiver = InputBoardSize();
printf ("Board Size value : %d, %d \n", testReceiver.n1, testReceiver.n2);
IntPair testReceiver;
testReceiver = InputBoardSize();
printf ("Board Size value : %d, %d \n", testReceiver.n1, testReceiver.n2);
testReceiver = InputStartRoachPosition();
printf ("Start Position value : %d, %d \n", testReceiver.n1, testReceiver.n2);
char testJourney[MAX_JOURNEY_LENGTH]="";
InputRoachJourney(testJourney);
printf ("Journey : %s \n", testJourney);
// For Input() Testing....
다음 모듈 - ScheduledWalk() 관련. Depth First 에 입각하여. 그리고 이쯤에서 TestDrivenDevelopment 를 약간 가미해봅시다.
(관련 페이지 참조, 또는 ["TestFirstProgramming"], ["UnitTest"])
// 일종의 Test Code. 프로그램이 완료되었다고 했을때 제가 원하는 상황입니다.
실행해보면, assert 부분에서 에러가 날 겁니다. 그러면서 assert 부분과 관련한 코드 라인을 표시해줍니다. 즉, 제가 원하는 상황을 가정하고 Test 코드를 만든뒤, 그 Test 를 통과할때까지 코드를 작성하면 되겠죠. 추후 뭔가가 작동이 이상하다라고 한다면,
2. Test Code 를 확인해본다.
- 데블스캠프2009/목요일/연습문제/MFC/서민관 . . . . 42 matches
// testMFCDlg.cpp : implementation file
#include "testMFC.h"
#include "testMFCDlg.h"
// CTestMFCDlg dialog
CTestMFCDlg::CTestMFCDlg(CWnd* pParent /*=NULL*/)
: CDialog(CTestMFCDlg::IDD, pParent)
//{{AFX_DATA_INIT(CTestMFCDlg)
void CTestMFCDlg::DoDataExchange(CDataExchange* pDX)
//{{AFX_DATA_MAP(CTestMFCDlg)
BEGIN_MESSAGE_MAP(CTestMFCDlg, CDialog)
//{{AFX_MSG_MAP(CTestMFCDlg)
// CTestMFCDlg message handlers
BOOL CTestMFCDlg::OnInitDialog()
void CTestMFCDlg::OnSysCommand(UINT nID, LPARAM lParam)
void CTestMFCDlg::OnPaint()
HCURSOR CTestMFCDlg::OnQueryDragIcon()
void CTestMFCDlg::OnButton1()
void CTestMFCDlg::OnButton2()
void CTestMFCDlg::OnButton3()
void CTestMFCDlg::OnButton4()
- 데블스캠프2009/목요일/연습문제/MFC/송지원 . . . . 41 matches
* TestDig.h
// testDlg.h : header file
#if !defined(AFX_TESTDLG_H__B619E89A_C192_46A8_8358_6AC21A6D48CC__INCLUDED_)
#define AFX_TESTDLG_H__B619E89A_C192_46A8_8358_6AC21A6D48CC__INCLUDED_
// CTestDlg dialog
class CTestDlg : public CDialog
CTestDlg(CWnd* pParent = NULL); // standard constructor
//{{AFX_DATA(CTestDlg)
enum { IDD = IDD_TEST_DIALOG };
//{{AFX_VIRTUAL(CTestDlg)
//{{AFX_MSG(CTestDlg)
#endif // !defined(AFX_TESTDLG_H__B619E89A_C192_46A8_8358_6AC21A6D48CC__INCLUDED_)
* TestDig.cpp
// testDlg.cpp : implementation file
#include "test.h"
#include "testDlg.h"
// CTestDlg dialog
CTestDlg::CTestDlg(CWnd* pParent /*=NULL*/)
: CDialog(CTestDlg::IDD, pParent)
//{{AFX_DATA_INIT(CTestDlg)
- VonNeumannAirport/1002 . . . . 40 matches
이를 Target으로 잡으려니, 더 커보이고, 이를 작은 Test 로 나눠봅니다.
#include <cppunit/TestCase.h>
#include <cppunit/Ui/Text/TestRunner.h>
class TestOne : public CppUnit::TestCase {
CPPUNIT_TEST_SUITE (TestOne);
CPPUNIT_TEST_SUITE_END();
CppUnit::TextUi::TestRunner runner;
class TestOne : public CppUnit::TestCase {
CPPUNIT_TEST_SUITE (TestOne);
CPPUNIT_TEST (test1);
CPPUNIT_TEST_SUITE_END();
void test1 () {
void test1 () {
여기까진 통과..~ test code 를 Refactoring 해봅니다.
void testOneToOneMove () {
void testOneToTwoMove () {
void testOneToTwoMove () {
이 경우 testOneToOneMove 가 깨지게 된다. 데이터형이 다르기 때문이다. testOneToOneMove 쪽 테스트 형을 똑같이 작성해준다.
void testOneToOneMove () {
1) test: TestOne::testOneToTwoMove (F) line: 66 C:\User\reset\AirportSec\main.c
- 데블스캠프2009/목요일/연습문제/MFC/정종록 . . . . 35 matches
// TestDlg.cpp : implementation file
#include "Test.h"
#include "TestDlg.h"
// CTestDlg dialog
CTestDlg::CTestDlg(CWnd* pParent /*=NULL*/)
: CDialog(CTestDlg::IDD, pParent)
//{{AFX_DATA_INIT(CTestDlg)
void CTestDlg::DoDataExchange(CDataExchange* pDX)
//{{AFX_DATA_MAP(CTestDlg)
BEGIN_MESSAGE_MAP(CTestDlg, CDialog)
//{{AFX_MSG_MAP(CTestDlg)
// CTestDlg message handlers
BOOL CTestDlg::OnInitDialog()
void CTestDlg::OnSysCommand(UINT nID, LPARAM lParam)
void CTestDlg::OnPaint()
HCURSOR CTestDlg::OnQueryDragIcon()
void CTestDlg::On2()
void CTestDlg::On3()
void CTestDlg::On1()
void CTestDlg::On4()
- TestFirstProgramming . . . . 32 matches
어떻게 보면 질답법과도 같다. 프로그래머는 일단 자신이 만들려고 하는 부분에 대해 질문을 내리고, TestCase를 먼저 만들어 냄으로서 의도를 표현한다. 이렇게 UnitTest Code를 먼저 만듬으로서 UnitTest FrameWork와 컴파일러에게 내가 본래 만들고자 하는 기능과 현재 만들어지고 있는 코드가 하는일이 일치하는지에 대해 어느정도 디버깅될 정보를 등록해놓는다. 이로서 컴파일러는 언어의 문법에러 검증뿐만 아니라 알고리즘 자체에 대한 디버깅기능을 어느정도 수행해주게 된다.
테스트코드는 프로그래머가 하려고 하는일, 즉 의도를 담아낸다. 이는 이 프로그램이 어떠한 시나리오로 돌아갈것인가를 먼저 생각해보는 기회를 저절로 제공해준다. Test가 가능한 코드는 run 을 시켰을때 어떤 결과를 낼지를 파악할 수 있는 코드이다. 이 경우 해당 모듈이 완성되었을때가 언제인지 그 목표를 분명하게 잡는 역할을 해준다.
ExtremeProgramming에서는 UnitTest -> Coding -> ["Refactoring"] 이 맞물려 돌아간다. TestFirstProgramming 과 ["Refactoring"] 으로 단순한 디자인이 유도되어진다.
요새는 ["TestDrivenDevelopment"] 라고 한다. 단순히 Test 를 먼저 작성하는게 아닌, Test 주도 개발인 것이다. TestDrivenDevelopment 는 제 2의 Refactoring 과도 같다고 생각. --["1002"]
* wiki:Wiki:CodeUnitTestFirst, wiki:Wiki:TestFirstDesign, wiki:Wiki:TestDrivenProgramming
* wiki:NoSmok:TestFirstProgramming
* wiki:Wiki:ExtremeProgrammingUnitTestingApproach
테스트 코드 작성에 대해서는 UnitTest 와 PyUnit, CppUnit 를 참조하라.
=== Test Code Refactoring ===
프로그램이 길어지다보면 Test Code 또한 같이 길어지게 된다. 어느정도 Test Code 가 길어질 경우에는 새 기능에 대한 테스트코드를 작성하려고 할 때마다 중복이 일어난다. 이 경우에는 Test Code 를 ["Refactoring"] 해야 하는데, 이 경우 자칫하면 테스트 코드의 의도를 흐트려뜨릴 수 있다. 테스트 코드 자체가 하나의 다큐먼트가 되므로, 해당 테스트코드의 의도는 분명하게 남도록 ["Refactoring"] 을 해야 한다.
* wiki:Wiki:RefactoringTestCode
=== Test - Code Cycle ===
=== Test Code Approach ===
Test Driven 에 대한 접근 방법에는 End-To-End (BlackBoxTesting) 식의 접근 방법과 WhiteBoxTesting 의 접근방법이 있을 수 있겠다.
Test - Code 주기가 길다고 생각되거나, 테스트 가능한 경우에 대한 아이디어가 떠오르지 않은 경우, 접근 방법을 다르게 가져보는 것도 하나의 방법이 될 수 있겠다.
Test Code 를 작성하진 않았지만, 이런 경험은 있었다. PairProgramming 을 하는 중 파트너에게
이 경우에도 ["MockObjects"] 를 이용할 수 있다. 기본적으로 XP에서의 테스트는 자동화된 테스트, 즉 테스트가 코드화 된 것이다. 처음 바로 접근이 힘들다면 Mock Server / Mock Client 를 만들어서 테스트 할 수 있겠다. 즉, 해당 상황에 대해 이미 내장되어 있는 값을 리턴해주는 서버나 클라이언트를 만드는 것이다. (이는 TestFirstProgramming 에서보단 ["AcceptanceTest"] 에 넣는게 더 맞을 듯 하긴 하다. XP 에서는 UnitTest 와 AcceptanceTest 둘 다 이용한다.)
- 데블스캠프2009/목요일/연습문제/MFC/박준호 . . . . 29 matches
// TestAPPDlg.cpp : implementation file
#include "TestAPP.h"
#include "TestAPPDlg.h"
// CTestAPPDlg dialog
CTestAPPDlg::CTestAPPDlg(CWnd* pParent /*=NULL*/)
: CDialog(CTestAPPDlg::IDD, pParent)
//{{AFX_DATA_INIT(CTestAPPDlg)
void CTestAPPDlg::DoDataExchange(CDataExchange* pDX)
//{{AFX_DATA_MAP(CTestAPPDlg)
BEGIN_MESSAGE_MAP(CTestAPPDlg, CDialog)
//{{AFX_MSG_MAP(CTestAPPDlg)
// CTestAPPDlg message handlers
BOOL CTestAPPDlg::OnInitDialog()
void CTestAPPDlg::OnSysCommand(UINT nID, LPARAM lParam)
void CTestAPPDlg::OnPaint()
HCURSOR CTestAPPDlg::OnQueryDragIcon()
void CTestAPPDlg::OnButton2()
void CTestAPPDlg::OnButton1()
void CTestAPPDlg::OnButton3()
void CTestAPPDlg::OnButton5()
- TestSuiteExamples . . . . 28 matches
여러 UnitTestFramework에서 TestSuite를 사용하는 예제들
import unittest
from TestA import *
from TestB import *
class AllTests(unittest.TestSuite):
suit = TestSuite()
suite.addTest(TestA())
suite.addTest(TestB())
# 사실 AllTests 자체를 완전히 빼버려도 됩니다. 그 이유는 from import *을 하기 때문입니다.
unittest.main(argv=('','-v'))
import unittest
return unittest.defaultTestLoader.loadTestsFromNames( ('ThePackage.test_file1','ThePackage.subpack.test_file2'))
unittest.TextTestRunner(verbosity=2).run(suite())
import junit.framework.Test;
import junit.framework.TestSuite;
public class AllTests {
public static Test suite() {
TestSuite suite = new TestSuite("Test for test");
suite.addTestSuite(LoginTest.class);
suite.addTestSuite(QueryObjectTest.class);
- TFP예제/WikiPageGather . . . . 23 matches
=== WikiPageGatherTestCase.py ===
import unittest
class WikiPageGatherTestCase (unittest.TestCase):
def testConvertWikiPageNameToMoinFileName (self):
def testGetPageNamesFromPage (self):
self.assertEquals (self.pageGather.GetPageNamesFromPage (), ["LearningHowToLearn", "ActiveX", "Python", "XPInstalled", "TestFirstProgramming", "한글테스트", "PrevFrontPage"])
def testGetPageNamesFromString (self):
strings = "Test First In TestFirstIn TesF TestFi guuweo StringIn"
self.assertEquals (self.pageGather.GetPageNamesFromString (strings), ["TestFirstIn", "TestFi", "StringIn"])
strings = '''["Testing"] ["Testing The Program"] higu TestFirst twet'''
self.assertEquals (self.pageGather.GetPageNamesFromString (strings), ["Testing", "Testing The Program", "TestFirst"])
def testIsHeadTagLine (self):
strings = "== testing =="
def testRemoveHeadLine (self):
strings = '''=== ExtremeProgramming ===\ntesting.. -_-a\n== TestFirst Programmin ==\nfwe\n'''
self.assertEquals (self.pageGather.RemoveHeadLine (strings), "testing.. -_-a\nfwe\n")
def testGetWikiPage(self):
'[[Include(ActiveX,Test,1)]]\n\n=== Python ===\n["Python"]\n\n' +
'=== ExtremeProgramming ===\n * ["XPInstalled"]\n * TestFirstProgramming\n'+
suite = unittest.makeSuite (WikiPageGatherTestCase, "test")
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/임상현,서민관 . . . . 23 matches
== testTest.java ==
import org.junit.Test;
public class testTest {
@Test
public void testConstructor1() {
@Test
public void testConstructor2() {
@Test
public void testConstructor3() {
@Test
public void testConstructor4() {
@Test
public void testgoTo1() throws Exception {
@Test(expected = Exception.class)
public void testgoTo2() throws Exception {
@Test(expected = Exception.class)
public void testgoTo3() throws Exception {
@Test
public void testupTo1() throws Exception {
@Test(expected = Exception.class)
- ProjectEazy/Source . . . . 22 matches
AllTest에서 폴더 안에 있는 모든 테스트 케이스를 자동으로 찾아서 실행하기
# EazyWordTest.py
import unittest
class EazyWordTestCase(unittest.TestCase):
def testAddCase(self):
unittest.main()
# EazyDicTest.py
import unittest
class EazyDicTestCase(unittest.TestCase):
unittest.main()
# EazyParserTest.py
import unittest
class EazyParserTestCase(unittest.TestCase):
def testFindFundermentalForm(self):
def testFindVerb(self):
def testFindVP(self):
def testFindNP(self):
unittest.main()
# AllTest.py
from EazyParserTest import *
- AcceptanceTest . . . . 21 matches
원문 : http://extremeprogramming.org/rules/functionaltests.html
AcceptanceTest는 UserStory들에 의해서 만들어진다. Iteration 동안 IterationPlanning 회의때 선택되어진 UserStory들은 AcceptanceTest들로 전환되어진다. Customer는 해당 UserStory가 정확히 구현되었을때에 대한 시나리오를 구체화시킨다. 하나의 시나리오는 하나나 그 이상의 AcceptanceTest들을 가진다. 이 AcceptanceTest들은 해당 기능이 제대로 작동함을 보장한다.
AcceptanceTest는 blackbox system test 이다. 각각의 AcceptanceTest는 해당 시스템으로부터 기대되는 결과물에 대해 표현한다. Customer는 AcceptanceTest들에 대한 정확성을 검증과, 실패된 테스트들에 대한 우선순위에 대한 test score를 검토할 책임이 있다. AcceptanceTest들은 또한 production release를 위한 우선순위의 전환시에도 이용된다.
UserStory는 해당 UserStory의 AcceptanceTest를 Pass 하기 전까지는 수행되었다고 생각할 수 없다. 이는 새로운 AcceptanceTest들은 각 Iteration 때 만들어져야 함을 뜻한다.
AcceptanceTest는 자동으로 수행되어져야 하며, 또한 그렇기 때문에 자주 실행될 수 있다. AcceptanceTest score는 개발팀에 의해 점수가 매겨진다. 매 Iteration에 대해 실패한 AcceptanceTest를 수정하기 위한 시간분배 스케줄에 대해서 또한 개발팀의 책임이다.
'AcceptanceTest'란 이름은 본래 'FunctionalTest' 로부터 온 것이다. 이는 ''Customer의 요구사항에 대해 system이 'acceptable' 함을 보증한다''라는 본래의 의도를 더 충실히 반영해준다.
요새는 CustomerTest 라고 표현하기도 한다. (UnitTest 를 ProgrammerTest 라고 부른다고 할때 상대적인 개념일듯).
["ProjectPrometheus"] 진행중에 ["1002"] 와 ["상민"]은 AcceptanceTest 를 작성하며 진행하였다. 주로 Python 을 이용하여 간단한 web bot 를 작성, 시스템이 잘 작동하는지에 대해 자동테스트를 구현했다.
(["ProjectPrometheus/AcceptanceTest"], 소스는 ZeroPageServer 의 CVS 프로젝트들중 AcceptanceTestServer 참조)
- NUnit/C++예제 . . . . 20 matches
* Test Fixture 될 클래스의 앞에는 TestFixture, 테스트 함수 앞에 Test 인 Attribute 를 붙인다.
[TestFixture]
[Test] void Add();
[Test] void Sub();
[Test] void Mul();
[Test] void Div();
* 헤더에다 다 구현해도 된다. 하지만 같은 이름의 cpp파일을 만들어줘야 하는것같다. 안그러면 Test없다고 안된다.
[TestFixture]
[Test]
[Test]
[Test]
[Test]
// TestCase.h
namespace TestCase
[TestFixture]
[Test]
void testAdd() {
[Test]
void testMult() {
Unmanaged C++에서 가장 좋왔던 방법은 Unmanaged C++ Project 두개를 만들어서, 한쪽으로 의존시킨후 assert 를 이용해 자체적인 Test Framework 을 작성해서 사용하는 방법이었다.
- RandomWalk2/재동 . . . . 20 matches
import unittest, random, os.path
class ReaderTestCase(unittest.TestCase):
def testCreateReaderClass(self):
def testReadTXT(self):
def testBoardLength(self):
def testStartPoint(self):
def testRoachPath(self):
class BoardTestCase(unittest.TestCase):
def testCreateBoardClass(self):
def testSetBoard(self):
class MoveRoachTestCase(unittest.TestCase):
def testCreateMoveRoachCalss(self):
def testMoveRoach(self):
def testCount(self):
class AllCaseTestCase(unittest.TestCase):
def testAllCase(self):
#unittest.main()
import unittest, random, os.path
class ReaderTestCase(unittest.TestCase):
def testCreaterdrClass(self):
- ExtremeProgramming . . . . 19 matches
ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.
초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.
Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 ["Refactoring"], 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.
개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> ["Refactoring"] 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. ["Refactoring"] 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.
* AcceptanceTest: 사용자 관점에서 해당 작업산출물이 제대로 돌아가는지 확인할 수 있는 테스트.
* UnitTest: 모든 클래스들에 대한 자동화된 테스트 코드들.
* TestDrivenDevelopment : Programming By Intention. 프로그래머의 의도를 표현하는 테스트코드를 먼저 작성한다. 그렇게 함으로서 단순한 디자인이 유도되어진다. (with ["Refactoring"])
* ContinuousIntegration: 매일 또는 수시로 전체 시스템에 대한 building 과 testing을 수행한다.
- UnitTest . . . . 18 matches
ExtremeProgramming 에서는 TestFirstProgramming 을 한다. TestFirstProgramming 에서는 해당 기능에 대한 테스트 프로그램을 먼저 만들고, 실제 프로그래밍을 한다.
TestFirstProgramming 을 하게 되면 해당 프로그램을 작성해 나가는 과정이 UnitTest 작성중 남게 된다. 이는 일종의 WhiteBoxTesting 이 된다. 또한, 해당 모듈이 제대로 돌아가는지에 대한 결과도 체크하므로 BlackBoxTesting 의 역할을 한다. 즉, ExtremeProgramming 에서의 UnitTest 는 두가지 테스트의 성격을 같이 포함하고 있다. (Gray Box Testing)
보통 테스트 코드를 작성할때는 UnitTestFramework Library들을 이용한다. 각 Language 별로 다양한데, C++ 사용자는 ["CppUnit"], Java 는 ["JUnit"], Python 은 ["PyUnit"] 등을 이용할 수 있다. PyUnit 의 경우는 2.1부터 기본 모듈에 포함되어있다.
See Also ["Refactoring/BuildingTestCode"], ["GuiTesting"]
SoftwareEngineering 에 있어서 UnitTest 는 '단위 모듈에 대한 테스트' 이다. 즉, 해당 기능이 제대로 돌아감을 확인하는 테스트가 UnitTest 이다.
우리는 실제로 프로그래밍을 하는 중간중간에 결과값을 출력해봄으로서 제대로 돌아감을 확인한다. 이 또한 UnitTest 라 할 수 있겠다. (단, Manual Test 로 분류해야 하겠다.) 올바른 결과값인지 확인하는 과정을 코드로서 만들어 넣는다면 이 테스트는 자동화시킬수 있을 것이다.
예를 든다면, 다음과 같은 것이 UnitTest Code 가 될 수 있겠다.
void testFactorial ()
void testFactorial ()
C 에서의 UnitTest Code 작성시에는 assert 문으로 비슷한 기능을 구현 할 수 있다.
A: MockObjects가 최적입니다. Socket이나 Database Connection과 동일한 인터페이스의 "가짜 객체"를 만들어 내는 겁니다. 그러면 Socket 에러 같은 것도 임의로 만들어 낼 수 있고, 전체 테스팅 시간도 훨씬 짧아집니다. 하지만 "진짜 객체"를 통한 테스트도 중요합니다. 따라서, Socket 연결이 제대로 되는가 하는 정도만(최소한도로) "진짜 객체"로 테스팅을 하고 나머지는 "가짜 객체"로 테스팅을 대체할 수 있습니다. 사실 이런 경우, MockObjects를 쓰지 않으면 Test Code Cycle을 통한 개발은 거의 현실성이 없거나 매우 비효율적입니다. --김창준
- Vending Machine/dooly . . . . 18 matches
import junit.framework.Test;
import junit.framework.TestSuite;
public class VendingMachineTest extends TestSuite {
public static Test suite() {
TestSuite suite = new TestSuite("Test for dooly.tdd.vending");
suite.addTestSuite(PerchaseItemTest.class);
suite.addTestSuite(RegistItemTest.class);
import junit.framework.TestCase;
public class PerchaseItemTest extends TestCase {
public void testWaitState() {
public void testPutMoney() {
public void testPerchase() {
public void testPerchaseWrongItem() {
public void testShortMoney() {
public void testRefund(){
import junit.framework.TestCase;
public class RegistItemTest extends TestCase {
public void testEmptyMatchine() {
public void testAddItem() {
public void testGetItem() {
- TestDrivenDevelopmentByExample/xUnitExample . . . . 17 matches
C++로 UnitTest프레임워크를 만들기 전에 책에 있는 파이선 예제를 따라하고 있습니다. 따라가는 과정은 책에 있습니다.
class TestCase:
result = TestResult()
result.testStarted()
result.testFailed()
class WasRun(TestCase):
def testMethod(self):
self.log += "testMethod "
def testBrokenMethod(self):
class TestResult:
def testStarted(self):
def testFailed(self):
class TestCaseTest(TestCase):
self.test = WasRun("testMethod")
def testTemplateMethod(self):
self.test.run()
assert "setUp testMethod tearDown " == self.test.log
def testResult(self):
result = self.test.run()
def testFailedResult(self):
- ClassifyByAnagram/김재우 . . . . 16 matches
== anagram_test.py ==
import unittest
class AnagramTest( unittest.TestCase ):
def testSortChar( self ):
def testAddWord( self ):
def testPrintAnagram( self ):
def testMainFunc( self ):
unittest.main()
== AnagramTest.cs ==
/// Summary description for AnagramTest.
[TestFixture]
public class AnagramTest
[Test]
[Test]
public void TestSortWord()
[Test]
public void TestAddWord()
== AnagramTest.java ==
import junit.framework.TestCase;
public class AnagramTest extends TestCase {
- 1002/Journal . . . . 15 matches
7 (토): Prometheus Test Code 추가 대장정
기존의 AcceptanceTest 들이 작동을 못한다. (Python 에서 정규표현식 이용. 데이터 파싱 & 추출. Prometheus UI 가 바뀌면 다시 바뀜) 전에 구경한 것처럼 XPath 를 이용하는 방법을 궁리해보거나, Prometheus 쪽에서 XML + XSLT 를 이용하는 방법을 궁리했다. 하지만, 그러기엔 현재 Prometheus 의 JSP 부분을 전부 바꾸는데 부담이 크리라 판단, Servlet Controller 중 Service 클래스 부분에 대해 테스트 코드를 붙이는 방법을 생각해 냈다. 하지만, 막상 작성해보고 나니 그 또한 테스트 코드의 크기가 크긴 하다.
Service 와 Controller 가 거의 Composition 이고, 그로 인해 Controller 는 Mapper, Recommender 들이 줄줄히 의존성을 가졌다. 각각의 Mapper, Recommender 들이 DB 를 쓰므로 이를 Mock Object 를 쓸까 하다가, 어차피 현재 작성하는 부분이 AcceptanceTest 의 일부이므로 실제 객체를 그냥 이용해도 좋겠다고 판단, 그대로 이용하고 작성.
Test 통과하는 만큼만이 내가 만든것이니. 더도말고 덜도말고. 걱정말자 걱정말자 걱정말자. -_-;
이번에 리팩토링을 하려고 할때 Legacy Code Refactoring 이라고 상정해서 그럴까. Coverage Test를 완벽하게 작성하는 것에 대해 부담감을 느꼈다. 예전에 유용했었던 '아아. 이미 다 되어있어요.~' 를 다시 적용해볼까.
from TestDrivenDevelopmentByExample
Refactoring 을 하기전 Todo 리스트를 정리하는데만 1시간정도를 쓰고 실제 작업을 들어가지 못했다. 왜 오래걸렸을까 생각해보면 Refactoring 을 하기에 충분히 Coverage Test 코드가 없다 라는 점이다. 현재의 UnitTest 85개들은 제대로 돌아가지만, AcceptanceTest 의 경우 함부로 돌릴 수가 없다. 왜냐하면 현재 Release 되어있는 이전 버전에 영향을 끼치기 때문이다. 이 부분을 보면서 왜 JuNe 이 DB 에 대해 세 부분으로 관리가 필요하다고 이야기했는지 깨닫게 되었다. 즉, DB 와 관련하여 개인 UnitTest 를 위한 개발자 컴퓨터 내 로컬 DB, 그리고 Integration Test 를 위한 DB, 그리고 릴리즈 된 제품을 위한 DB 가 필요하다. ("버전업을 위해 기존에 작성한 데이터들을 날립니다" 라고 서비스 업체가 이야기 한다면 얼마나 황당한가.; 버전 패치를 위한, 통합 테스트를 위한 DB 는 따로 필요하다.)
Prometheus 코드를 다시 checkout 하고 UnitTest 깨진 부분을 보면서 기존의 TDD 진행 보폭이 얼마나 컸는지가 보였다. (다시 Green Bar 를 보이게끔 하기에 진행해야 할일이 많았으니까. Extractor Remote Test 가 no matched (정규표현식에서 매칭 실패)로 깨졌을때 생각해야 할 일이 두가지이다. 하나는 HTML 이 제대로 받아졌는가(또는 HTML 이 도서관에서의 에러코드를 반환하는가), 하나는 extractor 가 그 구실을 제대로 하는가. 그런데, 테스트 코드를 보면 저 두가지가 묶여있다.
http://www.utdallas.edu/~chung/patterns/conceptual_integrity.doc - Design Patterns as a Path to Conceptual Integrity 라는 글과 그 글과 관련, Design Patterns As Litmus Paper To Test The Strength Of Object Oriented Methods 라는 글을 보게 되었는데, http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps 이다. 디자인패턴의 생성성과 관련, RDD 와 EDD 가 언급이 되는 듯 하다.
void testCalculate () {
void test() {
testCalculate();
void testGetCoverBoxSize() {
* ["ProgrammingContest"] , ["IpscAfterwords"]
* SWEBOK Construction 부분 한번 더 봄. 하지만 여전히 마음에 안들어하는중; (상민쓰 말처럼 '영어로 된 동화책 읽고 세익스피어 영문판 읽어야' 이해하는 내용이여서 그런가;) Code Construction 은 아무래도 Design 영역이나 Test 영역에 비해서 art (예술 또는 기술) 적인 측면이 커서 그러려나. 이건 다른 레퍼런스를 보는 것이 나을 것 같다. 한계를 생각하자.
- 05학번만의C++Study/숙제제출4/조현태 . . . . 14 matches
#include "TestClass.h"
TestClass* makedClass[MAX_CLASS];
makedClass[classNumber]=new TestClass(intinput);
=== TestClass.h ===
class TestClass
TestClass(int inputNumber);
~TestClass();
=== TestClass.cpp ===
#include "TestClass.h"
TestClass::TestClass(int inputNumber)
TestClass::~TestClass()
int TestClass::GetNumber()
- NUnit . . . . 14 matches
[http://nunit.org/ NUnit] 은 .Net 언어들을 위한 UnitTest Frameworks 이다.
* NUnit 은 pyunit과 junit 과 달리, .Net Frameworks 에 도입된 Source 내의 Meta Data 기록인 Attribute 으로 {{{~cpp TestFixture}}}를 구성하고 테스트 임을 만방에 알린다.
* 어떠한 클래스라도 즉시 Test를 붙일수 있다. (반면 JUnit 은 TestCase 를 상속받아야 하기 때문에, 기존 product소스가 이미 상속 상태라면 Test Fixture가 될수 없다. )
* 스크린 샷에서 처럼, 함수 이름이 Test 세팅에 종속적이지 않다. (반면 JUnit 은 reflection으로 Test 메소드들을 찾아내므로, Test의 이름들이 testXXX 와 같은 형태여야 한다.)
* Attribute이 익숙하지 않은 상태라 Test 를 상속받은 후 SetUp과 TearDown 의 실행점이 명쾌하지 못했다. 즉, 학습 비용이 필요하다.
* Java 1.5 에 메타 테그가 추가되면 NUnit 방식의 TestCase 버전이 나올것 같다. 일단 이름의 자유로움과, 어떠한 클래스라도 Test가 될수 있다는 점이 좋왔다. 하지만, TestFixture 를 붙여주지 않고도, 목표한 클래스의 Test 들을 실행할 수 있는 방식이면 어떨까 생각해 본다. --NeoCoin
See Also UnitTestFramework
- NUnit/C#예제 . . . . 14 matches
1. 테스트 하고자 원하는 Method 에는 Test를, 속한 클래스에는 TestFixture Attribute를 붙인다.
1. NUnit gui나 console 브라우져로 빌드후 나온 dll 혹은 exe를 로딩해서 Test를 실행한다.
[TestFixture]
public class AssertTester
[Test] public void 더하기와빼기()
[Test]
[Test]
[TestFixture]
public class FileTester
String fileName = "_________Test";
[Test] public void 파일확인()
== 단축키로 콘솔에서 UnitTest 실행하기 ==
1. 아래에 있는 Title에는 자기가 적고 싶은 이름( 예:NUnit Test(Console) )을 적는다.
- TheWarOfGenesis2R/Temp . . . . 14 matches
class Test
Test(int a1, int b1)
~Test()
typedef shared_ptr<Test> TestPtr;
vector<TestPtr> con;
TestPtr test1( new Test(1,2) );
TestPtr test2( new Test(3,4) );
TestPtr test3( new Test(5,6) );
TestPtr test4( new Test(7,8) );
con.push_back(test1);
con.push_back(test2);
con.push_back(test3);
con.push_back(test4);
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/김준석,서영주 . . . . 13 matches
public class ElevatorTest {
@Test
public void createTest(){
@Test
public void goToTest(){
@Test
public void printTest(){
@Test
public void callTest(){
@Test
public void getMaxHeightTest(){
@Test
public void getMinHeightTest(){
- JUnit/Ecliipse . . . . 12 matches
O'REILLY 사의 Eclipse(저자 Steve Holzner) 를 구입하시거나 제본하신 분들께서는 CHAPTER 3. Testing and Debugging 을 보시면 Sample 예제와 함께 자세한 설명이 있음을 알려드립니다.
이클립스의 Workspace 중 Pakage Expolorer 를 보시면 Ch03_01.java 파일이 있습니다. 여기서 마우스 오른쪽 버튼을 클릭 -> NEW -> JUnit Test Case 를 선택합니다.
다음으로 자신이 테스트를 하고 싶은 메서드에 체크를 하고 Finish 하면 TestCase를 상속받는 새 클래스를 자동으로 생성하여 줍니다.
public class Ch03_01Test extends TestCase {
* @see TestCase#setUp()
* @see TestCase#tearDown()
public void testAllocate() {
public void testGet() {
public void testSet() {
public class Ch03_01Test extends TestCase {
Ch03_01 testObject;
* @see TestCase#setUp()
testObject = new Ch03_01();
* @see TestCase#tearDown()
public void testAllocate() {
assertNotNull(testObject.allocate());
public void testGet() { assertEquals(testObject.get(1),1);
public void testSet() {
assertTrue(testObject.set(2,3));
테스팅을 원하는 코드를 추가했으므로, Urs As -> JUnit Test 메뉴를 클릭하여 실행합니다.
- PragmaticVersionControlWithCVS/CommonCVSCommands . . . . 12 matches
U sesame2/sesame2/templates/test.test
cvs server: Updating UnitTest
P UnitTest/DesignIssues.tip
U UnitTest/InAProject.tip
P UnitTest/Introduction.tip
cvs server: Updating UnitTest/code
U UnitTest/code/Age.java
U UnitTest/code/TestMyStack.java
U UnitTest/code/testdata.txt
cvs server: Updating UnitTest/code/rev1
cvs server: Updating UnitTest/code/rev2
cvs server: Updating UnitTest/code/rev3
root@eunviho:~/tmpdir/sesame/template2# cvs add test.txt
cvs add: scheduling file `test.txt' for addition
/home/CVSHOME/sesame/template2/test.txt,v <-- test.txt
- PrimaryArithmetic/1002 . . . . 12 matches
class PrimaryArithmeticTest(unittest.TestCase):
def testCarry(self):
class PrimaryArithmeticTest(unittest.TestCase):
def testCarry(self):
def testCarryOne(self):
def testToList(self):
def testToList(self):
class PrimaryArithmeticTest(unittest.TestCase):
def testCarry(self):
일단, testToList 부터. 문제 스펙에서 '10자리 미만 수'라는 점을 그냥 이용해도 될 것 같다는 생각이 들었다.
def testToList(self):
def testCarry(self):
testSet = [
for eachTest in testSet:
one,two,expected= eachTest
import unittest
class PrimaryArithmeticTest(unittest.TestCase):
def testCarry(self):
testSet = [
for eachTest in testSet:
- ProjectPrometheus/AcceptanceTestServer . . . . 12 matches
Acceptance Test 환경 만들기 - Python 으로 작성. 165.194.17.55 에서 AcceptanceTest 웹서버 돌리기.
AcceptanceTest / Search Test One , Two 등 테스트 리스트가 나오고, 실행을 할 수 있다.
해당 AcceptanceTest 의 Run 를 클릭하면, WEB 에서 해당 AcceptanceTest (UnitTest 작성 코드) 를 실행하고, 그 결과를 그대로 화면에 출력한다. 그러면 해당 테스트에 대한 결과를 확인할 수 있다.
Acceptance Test Server :
Python CGI 로 작성된 Acceptance Test 용 서버 -> Acceptance Test 에 대해서 출력 양식. AcceptanceTest 스펙을 구체적으로 명시해둘것.
Test Prometheus Server :
- SpiralArray/Leonardong . . . . 12 matches
import unittest
class SpiralArrayTest(unittest.TestCase):
def testMoveDown(self):
def testMoveUp(self):
def testIsWall(self):
def testGoStraightRight(self):
def testMark(self):
def testStorePointCoordinate(self):
def testStoreMoveCount(self):
def testTurnRound(self):
def testIsFinished(self):
def testConstructArray(self):
## unittest.main()
import unittest
class SpiralArrayTest(unittest.TestCase):
class DirectionTest(SpiralArrayTest):
def testNext(self):
def testPrevious(self):
class BoardTest(SpiralArrayTest):
def testIsWall(self):
- APlusProject/QA . . . . 11 matches
Upload:TestChase.zip - n-unit 테스트 한거 정리한 한글파일입니다-- 윤주 6월4일 이거는 다른 사람이 다운 받을 필요 없는 제 정리 문서입니다.
Upload:APP_UnitTestPlan_0401-0507.zip -- 이전문서
Upload:APP_UnitTestPlan_0508.zip -- 최종문서 - 수정끝QA승인끝
Upload:APP_UnitTestResult_0516-0530.zip - 이전문서
Upload:APP_UnitTestResult_0601.zip - 최종문서 - 수정끝
Upload:APP_UnitTestResult_0609.zip -- index랑 페이지수 몇개 틀렸길래 수정해서 올립니다 -- QA승인끝
Upload:APP_UnificationTestPlan_0403-0418.zip - 이전문서
Upload:APP_UnificationTestPlan_0420.zip - 최종문서 - 수정끝QA승인끝
Upload:APP_UnificationTestResult_0530.zip - 이전문서
Upload:APP_UnificationTestResult_0606.zip - 최종문서 - 수정끝
Upload:APP_UnificationTestResult_0609.zip -- 최종문서 index틀렸길래 수정해서 다시 올렸습니다 -QA승인끝!
- GuiTesting . . . . 11 matches
GuiTesting 을 하는 이유는 여러가지가 있을 수 있다. GUI Programming 에 대한 TestFirstProgramming 에 대한 시도를 할 수 있기 때문이다. 해당 UI Control을 하나하나 만드는 일부터 시작할 수 있다. 하지만, 보통의 경우 UI Control을 만드는 일들은 IDE 툴들에서 하는 것이 더 편하다. GuiTesting 은 해당 이벤트 발생시에 따른 처리과정에 대한 TestFirstProgramming 을 시도하려고 할 때 도움을 줄 것이다.
대부분의 경우는 TFP를 하는중에 logic 부분과 UI 부분을 분리함으로서 GuiTesting 을 복잡하게 하는 요소들을 줄일 수 있다. 그러면서 Model - View - Controler 의 형태가 유도되어질 것이다.
See Also wiki:Wiki:GuiTesting, wiki:Wiki:GuiUnitTesting, [http://www.xp123.com/xplor/xp0001/ JavaGuiTesting] , ["GuiTestingWithMfc"], ["GuiTestingWithWxPython"]
["UnitTest"]
- TFP예제/Omok . . . . 11 matches
=== TestCaseBoard.py ===
import unittest
class BoardTestCase (unittest.TestCase):
def testBoardEmpty (self):
def testIsExistDolInPosition (self):
def testDol (self):
def testPrintEmptyBoard (self):
suite = unittest.makeSuite (BoardTestCase, "test")
runner = unittest.TextTestRunner ()
=== TestCaseOmok.py ===
import unittest
class OmokTestCase (unittest.TestCase):
def testIsExistDolInPosition (self):
def testChangeCurrentDol (self):
def testFirstDolIsBlackInStart (self):
def testPutDol (self):
def testCurrentDol (self):
def testCheckFiveLeftTopToRightBottom (self):
def testCheckFiveLeftBottomToRightTop (self):
def testCheckFiveHorizon (self):
- 데블스캠프2013/셋째날/머신러닝 . . . . 11 matches
News[] testNews = new News[7528];
testNews[i].words = new int[SIZEBIG];
reader = new StreamReader(@"C:\ZPDC2013\test_data7528x8165");
testNews[count].words[i] = Convert.ToInt32(temp1[i]);
diffTemp = testNews[i].words[k] - sampleNews[j].words[k];
testNews[i].category = sampleNews[idx].category;
Console.WriteLine("{0} : {1}", i, testNews[i].category);
Console.WriteLine(testNews[i].category);
testData = open('DataSet/test_data7528x8165').readlines();
testClass = list();
for i in range(len(testData)):
diffValue = compare(testData[i], trainData[j]);
testClass.append(trainClass[similiarIndex]);
f = open("test_class")
for i in testClass:
ifstream testData;
testData.open("test_data7528x8165");
vector<string> testDataList = vector<string>();
vector<string> testClass = vector<string>();
while ( testData.good() ) {
- 3N+1Problem/Leonardong . . . . 10 matches
import unittest
class AOI3nPlus1ProblemTestCase(unittest.TestCase):
def testGetMaximumCycleLength(self):
def testGetCycleLength(self):
## unittest.main()
import unittest
class AOI3nPlus1ProblemTestCase(unittest.TestCase):
def testGetMaximumCycleLen(self):
def testGetCycleLen(self):
def testStoreCycles(self):
def testTime(self):
unittest.main(argv=('','-v'))
import unittest
TEST_MAX = 100000
##TEST_MAX = MAX - 1
class MyTestCase(unittest.TestCase):
def testGetCycleLen(self):
tests = [(1,1), (9,20), (16,5), (MAX-1,259)]
for n, expected in tests:
def testgetMaxCycleLen(self):
- CubicSpline/1002/test_NaCurves.py . . . . 10 matches
import unittest
class TestGivenFunction(unittest.TestCase):
def testOne(self):
def testPow(self):
def testMany(self):
class TestLagrange(unittest.TestCase):
def testFunctionExistence(self):
def testInsertPointX(self):
def testInsertPointY(self):
def testSubBasedFunctionOne(self):
def testSubBasedFunctionTwo(self):
def testSubBasedFunctionMany(self):
def testBasedFunctionOne(self):
def testBasedFunctionTwo(self):
def testLagrangeFunction(self):
def testInterpolation(self):
def testOne(self):
def testTwo(self):
def testThree(self):
class TestPiecewiseLagrange(unittest.TestCase):
- JTDStudy/첫번째과제/상욱 . . . . 10 matches
import junit.framework.TestCase;
public class NumberBaseBallGameTest extends TestCase {
public void testInputNumber() {
String testString = object.inputNumber();
if (testString.charAt(0) == '1' &&
testString.charAt(1) == '2' &&
testString.charAt(2) == '3')
public void testCreateResultNumber() {
public void testCheckScore() {
* 테스트 코드를 갖고 어떻게 해야하는지 잘 모르겠어요. import junit.framework.TestCase 구문이 있던데 이것은 어디서 가져와야 하나요? -_-;; - [문원명]
package test;
import org.junit.Test;
public class JUnit41Test {
@Test
import junit.framework.TestCase;
public class JUnit38Test extends TestCase {
- TestDrivenDevelopment . . . . 10 matches
사람마다 다를것 같긴 하지만, 나의 경우는 테스트를 작성하기 전 TODO List 를 작성할때 가장 고민을 하고 시간이 오래걸린 것 같다. 뭘 만들것인지에 대한 이해가 제대로 되지 않은 상태에서는 도대체 '뭘 해야 할지, 어떤 결과를 기대해야 할지'를 모르기 때문. :) 한편, 만일 TODO 리스트 작성시 시간이 너무 지체된다 싶으면 빨리 '어떤 결과를 기대해야 하나(Test 디자인)' 이란 질문을 하고 테스트를 작성해보는 방법을 추천. 저 질문이 앞에서의 '뭘 할까?'라는 질문의 모호함을 보완해주기 때문. 무엇을 해야 할지 감이 안올때는 가장 간단한 Input-Output 을 서술해봄으로서 조금씩 구체화시켜나갈 수 있음. '예제에 의한 구체화'란 방법은 참 유용함. --[1002]
...후략... ''-[TestDrivenDevelopment]에서''
int gNumTests = 0;
++gNumTests;
++gNumTests;
void printTestResult() {
printf("%d tests run, %d tests failed\n", (int)gNumTests,(int)gNumFailures);
printTestResult();
* [http://xper.org/wiki//xp/TestDrivenDevelopment?action=fullsearch&value=TestDrivenDevelopment&literal=1 XPER의 TDD 관련 자료들]
- 오목/인수 . . . . 10 matches
==== OmokTestCase.java ====
import junit.framework.TestCase;
public class OmokTestCase extends TestCase {
public OmokTestCase(String arg) {
public void testCreationBoard() {
public void testPutStone() {
public void testCheckInBoard() {
public void testCheckHeight() {
public void testCheckWidth() {
public void testCheckBackSlashDirection() {
public void testCheckSlashDirection() {
public void test6() {
public void test33() {
==== OmokUITestCase.java ====
import junit.framework.TestCase;
public class OmokUITestCase extends TestCase {
public OmokUITestCase(String arg) {
public void testPutStoneToValidLocation() {
public void testCoordinateToArrayIndex() {
- JTDStudy/첫번째과제/원명 . . . . 9 matches
* 처음에는 Test-Driven Development 에 입각하여 만들어 보려고 했으나, Java를 거의 처음 시작하고 프로그래밍 경험의 공백기간이 길었던게 큰 타격이었습니다ㅠㅠ. 결국에는 문법과 알고리즘에만 신경을 쓰다보니 TDD방식으로 다루기가 쉽지 않네요. 개선 조언을 해 주신 류상민 선배님 감사합니다 ㅎㅎ -[문원명]
* 오해가 있을 것 같아서 코멘트 합니다. TDD는 별로 중요하지 않습니다. 결정적으로 저는 '''TDD로 하지 않았습니다.''' 그냥 Refactoring시 Regression Test를 위해서 JUnit 을 썼을 뿐이에요.--NeoCoin
@Test
public void test2() {
@Test
public void test2() {
@Test
해당 함수를 알고리즘에 적용, Test는 계속 녹색 .
package test;
import org.junit.Test;
@Test
@Test
public void test2() {
- MockObjects . . . . 9 matches
UnitTest를 위한 일종의 보조객체.
실제의 객체역할을 흉내내는 일을 하는 객체이다. 보통 MockObject라는 클래스를 상속받아서 (구현은 각 언어별로 '알아서'이다. ^^; 처음 Mock 의 개념이 나온 컬럼은 Java 소스였다.) 만들어준다. 테스트를 위해서는 처음에 해당 객체에 초기설정을 해 둔다. 그리고 Test를 돌리게 된다.
-> MockObjects 자체가 인터페이스정의를 위한 도구로 이용할 수 있다. (TestFirstProgramming 에서는 Test Code가 일종의 인터페이스를 정의하기 위한 방법으로 이용된다.)
사용 예2) Datatbase 와 관련된 프로그래밍에 대해서 UnitTest를 할때, DB Connection 에 대한 MockObject를 만들어서 DB Connection을 이용하는 객체에 DB Connection 객체 대신 넣어줌으로서 해당 작업을 하게끔 할 수 있다. 그리고 해당 함수 부분이 제대로 호출되고 있는지를 알기 위해 MockObject안에 Test 코드를 넣어 줄 수도 있다.
그리고 위와 같은 경우 UnitTest 코드의 중복을 가져올 수도 있다. 이는 상속과 오버라이딩을 이용, 해결한다.
* http://www.mockobjects.com/endotesting.html.
* http://www.mockobjects.com/papers/jdbc_testfirst.html - MockObjects를 이용한 JDBC 어플리케이션 TestFirstProgramming
* [http://www.pragmaticprogrammer.com/starter_kit/ut/mockobjects.pdf Using Mock Objects] (extracted from pragmatic unit testing)
["ExtremeProgramming"], ["UnitTest"]
- 미로찾기/상욱&인수 . . . . 9 matches
=== MazeTestCase ===
import junit.framework.TestCase;
public class MazeTestCase extends TestCase {
public MazeTestCase(String title) {
public void testCreation() {
public void testMovement() {
public void testMovement2() {
public void testJudge() {
public void testEnd() {
=== ComplexMazeTestCase ===
import junit.framework.TestCase;
public class ComplexMazeTestCase extends TestCase {
public void testBlocked() {
public void testAll() {
public void testAcceptance1() {
public void testAcceptance2() {
- BabyStepsSafely . . . . 8 matches
This article outlines the refactoring of an algorithm that generate the prime numbers up to a user specified maximum. This algorithm is called the Sieve of Eratosthenes. This article demonstrates that the granularity of the changes made to the source code are very small and rely completely on the ability to recompile and test the code after every change no matter how small. The step where the code is tested insures that each step is done safely. It is important to note that the execution of tests do not actually guarantee that the code is correct. The execution of the tests just guarantees that it isn't any worse that it used to db, prior to the change. This is good enough for the purposes of refactoring since we are tring to not damage anything thay may have worked before Therefore for each change in the code we will be recompilling the code and running the tests.
The test cases for the GeneratePrimes class are implemented using the JUnit testing framework. The tests are contained in class called TestGeneratePrames. There are a 5 tests for each return type (array and List), which appear to be similiar. Our first step to insure보증하다, 책임지다 that we are starting from a stable base is to make sure what we have works.
Therefore, recompile the both GeneratePrimes and TestGeneratePrime and run the tests.
Class TestsGeneratePrimes
public class TestGeneratePrimes extends TestCase
public TestGeneratePrimes(String name)
public void testPrime()
public void testListPrime()
public void testLots()
public void testListLots()
public void testBasic()
public void testListBasic()
public void testSingle()
public void testListSingle()
public void testZero()
public void testListZero()
Refactor Tests First
Our first activity is to refactor the tests. [We might need some justification정당화 for refactoring the tests first, I was thinking that it should tie동여매다 into writing the tests first] The array method is being removed so all the test cases for this method need to be removed as well. Looking at Listing2. "Class TestsGeneratePrimes," it appears that the only difference in the suite of tests is that one tests a List of Integers and the other tests an array of ints. For example, testListPrime and testPrime test the same thing, the only difference is that testListPrime expects a List of Integer objects and testPrime expects and array of int variables. Therefore, we can remove the tests that use the array method and not worry that they are testing something that is different than the List tests.
- JTDStudy/두번째과제/장길 . . . . 8 matches
== TestButtonMain ==
public class TestButtonMain extends Applet implements ActionListener{
public TestButtonMain(){
TestFrame t= new TestFrame();
== TestFrame ==
public class TestFrame extends Frame implements WindowListener{
public TestFrame(){
- LoadBalancingProblem/임인택 . . . . 8 matches
TestSuite suite = new TestSuite();
suite.addTestSuite(TestLoadBalancing.class);
TestRunner.run(suite);
== TestLoadBalancing.java ==
public class TestLoadBalancing extends TestCase{
public void testSetNGetData() {
public void testGetSumOfJob() {
public void testCheckLeftRight() {
public void testLoadBalancing() {
- NSIS/예제1 . . . . 8 matches
Name "TestInstallSetup"
OutFile "TestInstallSetup.exe"
InstallDir $PROGRAMFILES\TestInstallSetup
Name: "TestInstallSetup"
OutFile: "TestInstallSetup.exe"
InstallDir: "$PROGRAMFILES\TestInstallSetup"
Output: "C:\Program Files\NSIS\TestInstallSetup.exe"
==== 만들어진 TestInstallSetup.exe 실행결과 ====
- PrimaryArithmetic/sun . . . . 8 matches
테스트 작성 (NumberGeneratorTest.java)
import junit.framework.TestCase;
public class NumberGeneratorTest extends TestCase {
public void testNoNumber() {
public void test123() {
지금 생각해보면 {{{~cpp testNoNumber}}}는 필요없는것 같다. 나중에 글을 쓰다보니, 같이 쓰게 됬는데 원래는 위의 테스트를 먼저 작성하고 테스트 통과후 아래쪽 테스트를 추가했다. 이번 작업과 별도로 '''코딩후에 뭔가하자'''는 결국 놓치는게 많다는걸 다시한번 증명하게 된다. :) ''see [http://jania.pe.kr/wiki/jwiki/moin.cgi/NowOrNever NowOrNever]''
테스트 작성 (PrimaryArithmeticTest.java)
import junit.framework.TestCase;
public class PrimaryArithmeticTest extends TestCase {
public void testCases() {
- PyIde/Exploration . . . . 8 matches
BoaConstructor 로 UI 작업하고, 위험하겠지만 어차피 Spike 라 생각하고 Test 없이 지속적으로 리팩토링을 해 나가면서 prototype 을 만들어나갔다. StepwiseRefinement로 진행하니까 코드가 짧은 시간에 읽기 쉽고 빨리 진행되었다.
Design 을 할때 오버하는 성향이 있는 것 같다. IListener 가 있으면 DIP를 지키는 것이기도 하고, 기존 TestResult 등의 클래스들을 수정하지 않으면서 Listener 들만 추가하는 방식으로 재사용가능하니까 OCP 상으로도 좋겠지만. 과연 당장 필요한 것일까? 그냥 TestResult 를 모델로 들고 있고 View 클래스 하나 더 있는 것으로 문제가 있을까?
SimpleTestResult Spike. result 결과물 잘 받아진다. Result 에 listener 연결해주면 테스트 실행, 정지, 성공, 실패일때마다 listener 로 메세지를 날린다. 나중에 GUI Runner 쪽에서 listener 를 implements 해주면 될듯.
unittest 모듈을 프린트하여 Code 분석을 했다. 이전에 cgi 로 test runner 돌아가게끔 만들때 구경을 해서 그런지 별로 어렵지 않았다. (조금 리팩토링이 필요해보기는 코드같긴 하지만.. JUnit 의 경우 Assert 가 따로 클래스로 빠져있는데 PyUnit 의 경우 TestCase 에 전부 implementation 되어서 덩치가 약간 더 크다. 뭐, 별 문제될 부분은 아니긴 하다.
약간만 Refactoring 해서 쓰면 될듯. Runner abstract class 추출하고, TestResult 상속받은 클래스 만들고,. Test Loading 은 TestLoader 그대로 쓰면 될것 같다.
Eric 의 Qt Unittest 모듈이랑, PyUnit Tkinter 코드를 보니, 거의 바로 답이 나와버린 것 같긴 하다.
- REFACTORING . . . . 8 matches
* 기존의 "디자인 후 코딩' 법칙과 반대된다. (TestFirstProgramming 에서 UnitTest - ["Refactoring"] 이 맞물려 돌아간다)
* Refactoring 을 하기 위해서는 UnitTest code가 필수적이다. 일단 처음 Refactoring에 대한 간단한 원리를 이해하고 싶다면 UnitTest 코드 없이 해도 좋지만, UnitTest code를 작성함으로서 Refactoring 에 대한 효과를 높일 수 있다. (Refactoring 중 본래의 외부기능을 건드리는 실수를 막을 수 있다.)
== Refactoring 과 Test Code ==
["Refactoring/BuildingTestCode"]
["Refactoring"] 과 TestDrivenDevelopment 는 일종의 메타패턴이다. (여기에 개인적으로 하나 더 추가하고 싶다면 ResponsibilityDrivenDesign) 두개에 충실하면 ["DesignPattern"] 으로 유도되어지는 경우가 꽤 많다.
- WikiTextFormattingTestPage . . . . 8 matches
Revised 1/05/01, 5:45 PM EST -- adding "test" links in double square brackets, as TWiki allows.
If you want to see how this text appears in the original Wiki:WardsWiki, see http://www.c2.com/cgi/wiki?WikiEngineReviewTextFormattingTest
* CLUG Wiki (older version of WardsWiki, modified by JimWeirich) -- http://www.clug.org/cgi/wiki.cgi?WikiEngineReviewTextFormattingTest
* MoinMoin (MoinMoin 0.5) -- http://www.encrypted.net/~jh/moinmoin/moin.cgi/WikiTextFormattingTestPage
* Swiki (unknown version) -- http://rhkswikitest.swiki.net/12
* Kit-T-Wiki (TWiki 01) -- http://kit.sourceforge.net/cgi-bin/view/Main/WikiReviewTextFormattingTest
* TWiki (TWiki 03) -- http://twiki.sourceforge.net/cgi-bin/view/TWiki/WikiReviewTextFormattingTest
http://narasimha.tangentially.com/cgi-bin/n.exe?twiky%20editWiki(%22WikiEngineReviewTextFormattingTest%22)
* UseMod wiki (UseMod 0.88) -- http://www.usemod.com/cgi-bin/wiki.pl?WikiEngineReviewTextFormattingTest
This page contains sample marked up text to make a quick visual determination as to which Wiki:TextFormattingRules work for a given wiki. To use the page, copy the text from the edit window, and paste it in the wiki under test. Then read it.
The next line (4 dashes) should show up as a horizontal rule. In a few wikis, the width of the rule is controlled by the number of dashes. That will be tested in a later section of this test page.
This first section will test the Wiki:WikiOriginalTextFormattingRules.
View the page in the original Wiki:WardsWiki, note the numbering, and then compare it to what it looks like in the wiki being tested.
End of line weight test.
Here is a test of headings using "!"
Here is a test of headings enclosed in equal signs (=), one for the top level, one more for each lower level. Whitespace is '''not''' allowed outside of the equals signs, while whitespace is ''required'' on the inside (separating the header text and the equals signs).
WikiNameTest
This area will test WikiName validity.
Here is a .gif URL for testing: http''''''://c2.com/sig/wiki.gif (This link disabled by 6 single quotes after the http.)
http://rhkswikitest.swiki.net/.format
- JosephYoder방한번개모임 . . . . 7 matches
* [https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=1pibLA94VQ8Z1cckW8IOsedbQ9joDuCwwafH93jHDgv3l-ASNn_QW2rGhxrWT&hl=en_US Refactoring Testing and Patterns]
* 너무 당연하게 TestDrivenDevelopment라면 테스트부터 작성해야한다고 생각하고있었는데 TDD가 반드시 TestFirstDevelopment일 필요 없다는 말을 듣고 머리를 얻어맞은 것 같았다. 테스트를 언제 작성하는지가 중요한 게 아니라 테스트를 통해 빠르게 피드백을 얻는 것이 중요.
Test기법에 관해 캔트백의 예를 들며 말해줬는데 코드를 만들때는 되게하고, 완성하고, 최적화시키는 순서로 만들라고했다. 그래서 난 더럽게 우선 돌아가게 짠다. 고 위안했다. Test가 되게 하고 Refactoring을 하고 다시 돌아가게 하고. 순환관계를 다시 보기도했다. 그렇게 하면 영향이 덜가고 잘 돌아가겠지? 라고 생각했다.
* Test Driven Develope
* Test First Develope
- RegressionTesting . . . . 7 matches
RegressionTesting 는 SoftwareTesting 의 한 방법으로, 이미 해결된 문제들이 재출현 여부에 대하여 검사 하는것
원문 : http://www.wikipedia.org/wiki/Regression_testing
RegressionTesting 는 SoftwareTesting 의 한 방법으로, 테스터는 이미 해결된 문제들이 재출현 여부에 대하여 검사 한다.
그래서 대다수의 소프트웨어 개발 시점 중에는 버그를 고쳤을때 훌륭한 방법인가, 버그가 재작성되거나, 버그가 프로그램상의 하부 변화 이후에 규칙적으로 실행되는지 '''드러내는 테스트'''에 대하여 훌륭한 실행 방법들을 제시한다. 몇몇 프로젝트(내 생각에 Mozilla경우, Eclipse도 같은 시스템)는 자동화된 시스템으로 자동적으로 모든 RegressionTesting들을 규칙적으로(보통 하루나 주말단위로) 실행하고, 조사하도록 세팅되어 있다.
RegressionTesting는 ExtremeProgramming 소프트웨어 개발 방법론의 필수적인 부분이다. 소프트웨어 개발 주기에서 매번 마다 모든 소프트웨어 패키지들에 대하여 광범위하고, 반복적이고, 자동화된 전체 소프트웨어에 테스트를 통하여 그러한 디자인 문서들이 교체된다.
See Also NewTestsForOldBugs
- SeminarHowToProgramItAfterwords . . . . 7 matches
* ["neocoin"] : UnitTest에서 추구한 프로그램의 설계에서 Divide해 나가는 과정은 여태 거의 디자인 타임에서 거의 수행을 했습니다. 그래서 여태 Test를 위한 코드들과 디버그용 코드들을 프로그램을 작성할때마다 그런 디자인에도 많은 시간을 소요했는데, 아예 프로그램의 출발을 Test에서 시작한다는 발상의 전환이 인상 깊었습니다. --상민
* ["1002"] : 어제 Test Code : Product Code 간 중복 (return 0 !) 을 OAOO로 풀어서 Refactoring 을 해야 할 상황으로 규정짓는다는 말이 뒤통수를 한대 때리는 기분이였습니다;;
* 아까 발표때에도 이야기했지만, Code Review 를 위한 reverse-TDD (정도로 해둘까요? 이것도 관련 문서가 있을텐데. ) 를 해보는 것도 좋을 것 같네요. 코드 분석을 위한 test-code 작성이요. 즉, 이미 만들어져있는 코드를 테스트 코드라고 상정하고, 자신이 제대로 이해했는가에 대한 검증과정을 Test-Code 로 만드는 것이죠. 시간 있었으면 오늘 마저 시도해봤을텐데, 시간에 마음 쫓긴게 아쉽네요.
* ["Refactoring"] 책에서는 ''Refactor As You Do Code Review'' 에 Code Review 를 위한 Refactoring을 이야기 하는데, Refactoring 을 위해서는 기본적으로 Test Code 가 필요하다고 할때 여기에 Test Code를 붙일테니까 상통하는 면이 있긴 하겠군요.
- XpQuestion . . . . 7 matches
- '필요하면 하라'. XP 가 기본적으로 프로젝트 팀을 위한 것이기에 혼자서 XP 의 Practice 들을 보면 적용하기 어려운 것들이 있다. 하지만, XP 의 Practice 의 일부의 것들에 대해서는 혼자서 행하여도 그 장점을 취할 수 있는 것들이 있다. (TestDrivenDevelopment, ["Refactoring"], ContinuousIntegration,SimpleDesign, SustainablePace, CrcCard Session 등. 그리고 혼자서 프로그래밍을 한다 하더라도 약간 큰 프로그래밍을 한다면 Planning 이 필요하다. 학생이다 하더라도 시간관리, 일거리 관리는 익혀야 할 덕목이다.) 장점을 취할 수 있는 것들은 장점을 취하고, 지금 하기에 리스크가 큰 것들은 나중에 해도 된다.
개인적으로, TestDrivenDevelopment 는 연습해보면 배울 게 많다고 생각한다. Test 를 작성하는데에서 배웠던 일들이 많기에. (Test 를 작성하기 위해 큰 모듈덩어리에서 일어나는 중간단계에 대해 더 깊게 생각하고 작은단위로 쪼갠다던지, AcceptanceTest 를 작성하기 위해 전체 시스템 돌아가는 과정을 안다던지 등등)
- Story Card 는 Kent Beck 이 사용자와 더 빠른 피드백을 위해 생각한 덜 형식적인 방법이다. 어차피 Story Card 는 전부 AcceptanceTest 로 작성할 것이기에, 테스트가 작성되고 나면 AcceptanceTest 가 도큐먼트 역할을 할 것이다. Index Card 도구 자체가 보관용이 아니다. 보관이 필요하다면 위키를 쓰거나 디지털카메라 & 스캐너 등등 '보관용 도구', 'Repository' 를 이용하라.
- 만년달력/인수 . . . . 7 matches
=== CalendarTestCase.java ===
import junit.framework.TestCase;
public class CalendarTestCaseTest extends TestCase {
public CalendarTestCaseTest(String arg) {
public void test1Year() {
public void test2Year() {
public void test4Year() {
public void test2003Year() {
public void testMonthStartPoint() {
public void testLeapYear() {
- 5인용C++스터디/더블버퍼링 . . . . 6 matches
CTestView::CTestView()
void CTestView::OnDraw(CDC* pDC)
CTestDoc* pDoc = GetDocument();
int CTestView::OnCreate(LPCREATESTRUCT lpCreateStruct)
if (CView::OnCreate(lpCreateStruct) == -1)
void CTestView::OnTimer(UINT nIDEvent)
- ACM_ICPC/PrepareAsiaRegionalContest . . . . 6 matches
=== at On-line Preliminary Contest(Oct. 2, 2004) ===
int nTest;
fin >> nTest;
for ( int t = 0 ; t < nTest ; t++ ){
int nTest;
cin >> nTest;
for ( int t = 0 ; t < nTest ; t++ ){
- HardcoreCppStudy/두번째숙제/ConstructorAndDestructor/변준원 . . . . 6 matches
class Test{
Test();
~Test()
위에 간단한 코드에서 Test();가 생성자에 해당되며 Test obj1; 이라고
소멸자의 경우 ~Test(); 부분이 소멸자에 해당되고, 객체가 사라질때 호출되는데,
- Java/ModeSelectionPerformanceTest . . . . 6 matches
for (int i = 0; i < ModeChoicePerformanceTest.LOOPING_COUNT; i++) {
for (int i = 0; i < ModeChoicePerformanceTest.LOOPING_COUNT; i++) {
for (int i = 0; i < ModeChoicePerformanceTest.LOOPING_COUNT; i++) {
for (int i = 0; i < ModeChoicePerformanceTest.LOOPING_COUNT; i++) {
for (int i = 0; i < ModeChoicePerformanceTest.LOOPING_COUNT; i++) {
public class ModeChoicePerformanceTest {
- MagicSquare/재동 . . . . 6 matches
import unittest
class MagicSquareTestCase(unittest.TestCase):
def testCreation(self):
def testInitializeBoard(self):
def testBoard_3by3(self):
def testBoard_5by5(self):
#unittest.main()
import unittest
class MagicSquareTestCase(unittest.TestCase):
def testCreateMagicSquare(self):
def testInitializeBoard(self):
def testBoard_3by3(self):
def testBoard_5by5(self):
class CounterTestCase(unittest.TestCase):
def testCreateCounter(self):
def testSetBoard(self):
def testWriteFirstCell(self):
def testWriteNextCell(self):
unittest.main()
- MoreEffectiveC++/Techniques1of3 . . . . 6 matches
void performSelfTest();
void performSelfTest();
void performSelfTest();
p2->performSelfTest(); // 객체 사용하듯이 한다.
void performSelfTest();
=== Testing Smart Pointers for Nullness : 스마트 포인터의 더미(dumb)상의 null 여부를 알고 싶어! ===
- ProjectPrometheus/Iteration2 . . . . 6 matches
|| 7/18 || 1차 Iteration 에 대한 AcceptanceTest. 2차 Iteration 계획. ||
|| Book Search Acceptance Test 작성 || 1 || ○(2시간 30분) ||
||||||Acceptance Test (["ProjectPrometheus/AT_RecommendationPrototype"]) ||
|| Test || Test 내용 || Pass 여부 ||
|| {{{~cpp RecommendationBookTest}}}|| 가중치 순서대로 책 리스트 보여주기 테스트 || ○ ||
- RandomWalk2/TestCase2 . . . . 6 matches
test.exe 는 작성한 프로그램 실행 파일 이름입니다.
c:\RandomWalk2Test> alltest.bat test.exe
{{{~cpp C:\RandomWalk2Test> fc output1.txt e-output1.txt}}}를 통해 정답과 자동 비교를 해볼 수 있습니다.
==== Test1 ====
==== Test2 ====
==== Test3 ====
==== Test4 ====
- StringOfCPlusPlus/상협 . . . . 6 matches
String Test("The reverse function work well in English");
cout<<Test<<'\n';
Test.delspace();
cout<<Test<<'\n';
Test.reverse();
cout<<Test<<'\n';
- TestCase . . . . 6 matches
TestCase란 만들고자 하는 대상이 잘 만들어졌다면 무사히 통과할 일련의 작업을 말한다. TestCase는 작성하고자하는 모듈의 내부 구현과 무관하게
XP에서 TestCase를 먼저 작성함으로서 프로그래머가 내부 구현에 신경쓰다가 정작 그 원하는 동작(예를 들어, 다른 모듈과의 인터페이스)을 놓칠 위험을 줄여준다. 왜냐하면, 프로그래머는 먼저 만든 TestCase를 통과하는 것을 첫번 목표로 삼을 수 있기 때문이다.
-> Xp 에서 프로그래머는 TestCase 를 통과하는 것을 목표를 삼는다. 그래서 구현이나 디자인에 신경쓰다 원하는 모듈을 오동작으로 이끄는 위험을 줄인다.
See Also ["UnitTest"]
- 코바예제/시계 . . . . 6 matches
//TestTimeServer
module TestTimeServer {
//TestTimeServerImpl.java
class ObjTimeServerImpl extends TestTimeServer.ObjTimeServer_Skeleton {
TestTimeServer.ObjTimeServer TimeServer = TestTimeServer.ObjTimeServer_var.narrow(obj);
- ClassifyByAnagram/sun . . . . 5 matches
public class PowerTest extends Applet
AnagramTest anagram;
anagram = new AnagramTest();
anagram.add( "test" );
class AnagramTest
public AnagramTest()
- EightQueenProblem/강석천 . . . . 5 matches
=== BoardTestCase.py ===
import unittest
class BoardTestCase (unittest.TestCase):
def testBoardEmpty (self):
def testSetQueen (self):
def testPrintBoard (self):
def testIsSelftyZone (self):
def testFindQueenInSameVertical (self):
def testFindQueenInSameHorizonal (self):
def testFindQueenInSameCrossLeftTopToRightBottom (self):
def testFindQueenInSameCrossLeftBottomToRightTop (self):
def testGetFirstCornerInCrossLeftTopToRightBottom (self):
def testGetFirstCornerInCrossLeftBottomToRightTop (self):
def testIsAttackableOthers (self):
def testEightQueen (self):
def testGetUnAttackablePositon (self):
suite = unittest.makeSuite (BoardTestCase, "test")
runner = unittest.TextTestRunner ()
- EightQueenProblemDiscussion . . . . 5 matches
def testBoardEmpty (self):
def testSetQueen (self):
def testPrintBoard (self):
def testIsSelftyZone (self):
def testFindQueenInSameVertical (self):
def testFindQueenInSameHorizonal (self):
def testFindQueenInSameCrossLeftTopToRightBottom (self):
def testFindQueenInSameCrossLeftBottomToRightTop (self):
def testGetFirstCornerInCrossLeftTopToRightBottom (self):
def testGetFirstCornerInCrossLeftBottomToRightTop (self):
def testIsAttackableOthers (self):
def testGetUnAttackablePositon (self):
* Feelings - 느낀점: 시간이 넘 오래걸려서 한편으로는 쪽팔리긴 하다. -_-; 뭐.. 알고리즘 부분에 대해서 너무 시간을 오래 끌었다. 왜 그랬을까 생각하는데.. 아마 특정 알고리즘들이 먼저 머릿속에 떠올라서가 아닐까 한다. (이 부분에 대해서는 stack을 쓸까 recursive 로 대신할까 이리저리군시렁군시렁) 이런 부분에 대해서는 어떻게 test가능한 부분으로 접근해나갈수 있을까.
자신에게 항상 "What is the simplest thing that could possibly work?"라는 질문을 하면서 TestDrivenDevelopment를 했나요? 테스트/코드 사이클을 진행하면서 스텝을 작게 하려고 노력했나요? 중간에 진척이 별로 없는 경우, 어떤 액션을 취했나요? 그 때 테스트 사이클의 스텝을 더 작게하려고 했나요? 만약 다시 같은 문제를 새로 푼다면 어떤 순서로 테스트를 하고 싶나요? (직접 다시 한번 새로 시작하는 것도 강력 추천) 왜 다른 사람들에 비해 시간이 상대적으로 많이 걸렸을까요? 테스트 코드를 사용한 것이 그 시간만큼의 이득이 있었나요? TestDrivenDevelopment를 해내가면서 현재 패스하려고 하는 테스트 케이스에서 무엇을 배웠나요? 켄트벡이 말하는 것처럼 사고의 도구가 되어 주었나요? 참고로 저는 EightQueenProblem을 파이썬으로 약 30분 정도 시간에 50 라인 이내로(테스트 코드 제외) 풀었습니다. TestDrivenDevelopment로요. --김창준
직접 다시 새로 시작하는 것에 대해서는 비교계산을 내리기 힘들것 같네요. (더 좋은 디자인을 얻어내는 것과 훈련라는 점에서는 물론 저도 추천) 제가 잘못했다고 생각되는 부분은, 퀸을 배열하는 방법 알고리즘 부분에 대해 TestDrivenDevelopment 를 지키지 못했다는 점이죠. (머릿속에 먼저 재귀함수 호출 등의 특정 알고리즘들이 먼저 떠오른지라. )
즉, 실제 Queen의 위치들을 정의하는 재귀호출 코드인데요. 이 부분에 대한 TestCase 는 최종적으로 얻어낸 판에 대해 올바른 Queen의 배열인지 확인하는 부분이 되어야 겠죠. 연습장에 계속 의사코드를 적어놓긴 했었는데, 적어놓고 맞을것이다라는 확신을 계속 못했죠. 확신을 위해서는 테스트코드로 뽑아낼 수 있어야 할텐데, 그때당시 이 부분에 대해서 테스트코드를 못만들었죠.
* TFD로 시도하였는데. test와 code간 이동이 빠르지 못하였다. 즉, test부분이 충분히 작아지지 못한 것 같다.
- GuiTestingWithWxPython . . . . 5 matches
== test_myframe.py ==
import unittest
class TestFrame(unittest.TestCase):
def testFramePositionSize(self):
def testControls(self):
def testbuttonText(self):
expected = "testing"
def testButtonRect(self):
def testListBox(self):
expected = ('testing1', 'testing2', 'testing3')
class TestApp(wxApp):
testApp=TestApp(0)
unittest.main(argv=('','-v'))
def __init__(self, parent=NULL, id=NewId(), title='test', pos=(400,400), size=(400,400)):
self.button = wxButton(self, ID_BUTTON, "testing", pos=(100,100), size=(200,50))
self.listBox.Append('testing1')
self.listBox.Append('testing2')
self.listBox.Append('testing3')
["GuiTesting"]
- JUnit . . . . 5 matches
Java 언어를 위한 UnitTest Framework.
=== javatestrunner.bat ===
java junit.textui.TestRunner %1
=== javaguitestrunner.bat ===
java junit.swingui.TestRunner %1
JUnit 에서 UnitTest (PyUnit) 에서처럼 testing message 나오게 하려면 어떻게 해야 하죠..? -임인택
PyUnit 에서 argument 로 -v 를 주면 testing message 가 나오지 않습니까..?
OK (5 Tests)
- NSISIde . . . . 5 matches
* MFC 와 연결되는 부분에 대한 TestFirstProgramming 을 제대로 지키지 못했다. (아.. GUI 부분은 애매하다. --;) 애매한 부분에 대해서 예전에 하던 방식이 섞이다 보니까 리듬이 깨졌다. 차라리 철저하게 TFP로 가는게 나았었을텐데 하는 생각이 들었다.
* 하지만, View/Document 구조가 한편으로는 방해물이.. 이미 디자인이 되어버린 Framework 의 경우 어떻게 적용을 시켜나가야 할까. 일단 주로 알고리즘과 관련된 부분에 대해 Test Code를 만들게 되었다. 계속 생각해봐야 할 문제일 것이다.
* AcceptanceTest 를 중간에 짤 시간을 할당하지 못했다. (솔직히 GUI 부분이 들어가는 부분에 대해 감이 오질 않았다. 전에 Web Programming 때에는 직접 HTTP Protocol을 이용, 웹서버로부터 받아온 HTML 문서를 Parsing 한 뒤 그 결과에 대해 Test Code를 작성하는 식이였는데.. (그래도 Manual Test 목록이라도 작성해 두었어야 했는데 이건 계획단계의 실수라 생각)
- PairProgramming . . . . 5 matches
* 해당 시간 내 집중도의 상승, Pair Pressure - 평소 프로그래밍 외의 것(프로그래밍 중 음악듣기, 쓸데없는 웹서핑, 메일 읽기)에 대한 잡음을 없앤다. 작업 자체에만 몰두하게 해준다. ["TestDrivenDevelopment"] 와 상호작용이 빠른 언어(["Python"] 등..)를 이용하면 Feedback 이 빠르므로 집중도가 더 높아진다.
* 집단 삽질. --; - 이것은 헤프닝이라고 보는 것이. -_-;; Test Code 에서 둘이 라디안 구하는 공식을 거꾸로 쓰고 '왜 값이 틀리다고 하는거야!' 하며 1시간을 삽질했다는 후문이 있다는. --;
* 하지만 UnitTest도 그렇듯이, 많은 장점을 가진 방법을 완벽하지 않다는 이유로 사용하지 않는다는 것은 아쉬운 일일 것이다.
TestFirstProgramming 과 PairProgramming 은 집중도에 관해서는 가장 훌륭한 선택인 것 같다. (단, Pair와의 담합행위가 이루어지면 곤란하겠다. -_-;)
ProgrammingContest 에 있는 K-In-A-Row 문제를 푸는 일을 했다.
* 집중 - 이번 경우에는 '시간제한' 이라는 것까지 있어서인지; 석천은 더더욱 프로그래밍 자체에 집중했다. (스크립트 언어 스타일의 접근방법과 이전의 TDD 연습도 한몫 거든듯. 조금씩 만들고 결과 확인해보고 조금 또 만들어보고 결과 확인을 했다. 단, 이번엔 Test Code 를 안만들어서, 뒤에가서 버그가 났을때 대체를 못했다는.-_-; 잘될때는 문제가 아니다. 잘 안될때, 문제상황에 대한 대처가 중요하다고 생각.)
- ProjectPrometheus/AT_BookSearch . . . . 5 matches
import unittest
class TestAdvancedSearch(unittest.TestCase):
def testOne(self):
params = {'TI':'Test', 'AU':'', 'IB':'', 'PU':'', 'OP1':'','OP2':'','OP3':''}
def testKorean(self):
def testKoreanTwo(self):
class TestSimpleSearch(unittest.TestCase):
def testOne(self):
def testIsbn(self):
def testKoreanAndNumber(self):
def testKoreanAndNumberWithSpace(self):
unittest.main(argv=('','-v'))
- ProjectPrometheus/Iteration1 . . . . 5 matches
||||||Acceptance Test (["ProjectPrometheus/AT_BookSearch"]) ||
|| Test || 내용 || Pass 여부 ||
|| {{{~cpp TestAdvancedSearch}}} || 1. 제목에 'Test' 키워드로 검색. 70 개 이상 검색되면 성공. (<TR> 갯수로 카운팅) || ○ ||
|| {{{~cpp TestSimpleSearch}}} || 1. 키워드로 '한글'로 검색. 결과값이 10개 이상이면 성공. || ○ ||
- ProjectZephyrus/ThreadForServer . . . . 5 matches
'''1. CVS 를 이용해서 ProjectZephyrusServerTest 를 다운 받는다. '''
cvs co ProjectZephyrusServerTest
java junit.textui.TestRunner AllTests
Test는 본인이 하고 Journey에 적어라.
- RefactoringDiscussion . . . . 5 matches
* 코드의 의도가 틀렸느냐에 대한 검증 - 만일 프로그램 내에서의 의도한바가 맞는지에 대한 검증은 UnitTest Code 쪽으로 넘기는게 나을 것 같다고 생각이 드네요. 글의 내용도 결국은 전체 Context 내에서 파악해야 하니까. 의도가 중시된다면 Test Code 는 필수겠죠. (여기서의 '의도'는 각 모듈별 input 에 대한 output 정도로 바꿔서 생각하셔도 좋을듯)
로직이 달라졌을 경우에 대한 검증에 대해서는, Refactoring 전에 Test Code 를 만들것이고, 로직에 따른 수용 여부는 테스트 코드쪽에서 결론이 지어져야 될 것이라는 생각이 듭니다. (아마 의도에 벗어난 코드로 바뀌어져버렸다면 Test Code 에서 검증되겠죠.) 코드 자체만 보고 바로 잘못된 코드라고 단정짓기 보단 전체 프로그램 내에서 의도에 따르는 코드일지를 생각해야 될 것 같다는 생각.
우리에겐 프로그램의 옳음(correctness)이 일차적입니다. 이것은 ["UnitTest"]나 Eiffel 같은 DBC 언어로 상당한 정도까지 보장 가능 합니다.
- Server&Client/상욱 . . . . 5 matches
public class ServerSocketTest implements Runnable {
public ServerSocketTest() throws IOException {
ServerSocketTest sst = new ServerSocketTest();
public class SimpleSocketTest {
- TriDiagonal/1002 . . . . 5 matches
* 느낀점 - LU 분해를 일반화시키는 부분에 대해서는 연습장에서 계산을 시키고 대입을 해보고 패턴을 찾아낸 뒤 일반화시켰다. 만일 이 부분을 코드를 짜면서 ["TestFirstProgramming"] * ["Refactoring"] 의 방법으로 풀었더라면 어떠했을까. (두 개의 과정이 비슷하다고 여겨진다. 코드가 줄어들고 OAOO 의 원칙을 지킬 수 있을테니까.) -- 석천
=== test_lu.py - LU Decomposition 을 위한 test code ===
import unittest
class TestLuDecomposition(unittest.TestCase):
def testLwrite(self):
def testUwrite(self):
def testLuDecMore(self):
def testLuDecomposition(self):
unittest.main()
=== test_tridiagonal.py - tri-diagonal 부분에 대한 test-code ===
import unittest
class TestTridiagonal(unittest.TestCase):
def testGetMatrixY(self):
def testGetMatrixX(self):
unittest.main()
- VMWare/OSImplementationTest . . . . 5 matches
로드할 것입니다. ( no 플로피 부팅디스켓, no 리붓, no test machine )
test al,2
/nologo /base:"0x10000" /entry:"start" /subsystem:console /incremental:no /pdb:"Release/testos.pdb" /map:"Release/testos.map" /machine:I386 /nodefaultlib /out:"testos.bin" /DRIVER /align:512 /FIXED
Deleting intermediate files and output files for project 'testos - Win32 Release'.
--------------------Configuration: testos - Win32 Release--------------------
3 sectors, 1536 bytes read from file testos.bin...
testos.bin
컴파일을 마치고 나면 아래와 같은 탐색기 모습이 될 것입니다. 마지막으로 셍성된 testos.img 가 우리의 커널 이미지가 됩니다.
Upload:zeropage:VMWareOSImplementationTest01.gif
Upload:zeropage:VMWareOSImplementationTest02.gif
Upload:zeropage:VMWareOSImplementationTest03.gif
제일 중요한 것은 이렇게 만든 가상 testos 의 플로피 디스켓 부팅 설정입니다.
Upload:zeropage:VMWareOSImplementationTest04.gif
Upload:zeropage:VMWareOSImplementationTest05.gif
- 데블스캠프2009/수요일 . . . . 5 matches
|| 송지원 || Simple Java & JUnitTest || Java의 간단한 문법과 개념을 배우고,[[br]]JUnitTest를 통해 TDD 기반의 프로그래밍에 대해 맛보기. || 아무래도 Test가[[br]]메인이다 보니,[[br]]Java를 통한 OOP 개념의 실습은[[br]]시간상 진행하지 않는다. ||
||am 03:00~03:50 || 간단한 실습 -> Test 유도 || 송지원 ||
||am 04:00~05:00 || TDD의 개념과 JUnitTest 실습 || 송지원 ||
- 데블스캠프2011/첫째날/후기 . . . . 5 matches
* 2009년에 Java와 JUnitTest를 주제로 진행했을 때 실습 미션을 잘못 준비해오고 시간이 많이 비었던 뼈아픈 기억 때문에 시간이 부족했음에도 불구하고 나름 신경을 많이 썼던 섹션이었는데 오히려 타임오버가 되었네요;; 프로그래밍보다 수학 시간이 되었던거 같은 실습시간.. (그래서 처음에 겉넓이를 뺐던 것이었는데 팀이 많아서 추가하고 으헝헝) 그리고 다들 프로그래밍을 잘해서 '''Unit Test를 굳이 하지 않아도 버그가 없었던''' 프로그램을 완성하는 바람에.. Unit Test의 필요성을 많이 체감하지 못한것 같아서 좀 아쉬웠어요. 역시 '''적절한 예제'''를 만들기는 어려운것 같아요.
* java를 이번학기에 수강을 하였기 때문에 어느정도 자신이 있었습니다만, 지원누나의 설명을 들으면서 역시 알아야 할것은 많구나 라는 생각이 들었습니다. 특히 SVN을 사용한 커밋과 JUnit은 팀플할때에도 많은 도움이 될 것 같아 좀더 공부해 보고 싶어졌습니다. 저번 java팀플때는 Github을 사용했었는데 SVN과 무슨 차이점이 있는지도 궁금해 졌구요. JUnit Test는 제가 실제로 프로그래밍 하면서 사용하였던 원시적인 test와 많은 차이가 있어서 이해하기 힘들었지만 이 또한 더 사용하기 좋은 기능인것 같아 점 더 공부해 봐야겠습니다.
* 조성래 교수님의 수업을 듣고서도 자바에 대한 자신감이 그닥 크게 있지는 않았습니다. 하지만 지원이 누나의 강의를 들으면서 여러가지 많이 배웠습니다. 특히 JUnit Test라는 녀석 매우 신기했습니다. 다음부터 열심히 써먹어야겠어요.
- 3N+1Problem/황재선 . . . . 4 matches
import unittest
class ThreeNPlusOneTest(unittest.TestCase):
def testOneCal(self):
def testTwoCal(self):
unittest.main(argv=('','-v'))
import unittest
class ThreeNPlusOneTest(unittest.TestCase):
def testOneCal(self):
def testTwoCal(self):
unittest.main(argv=('','-v'))
- Applet포함HTML/영동 . . . . 4 matches
http://zeropage.org/~rimyd/apltest/apltest.html
즉, 영동군의 계정에서 ~/public_html 을 만들고 test.txt 란 파일을 넣으면, 외부에서는 http://zeropage.org/~rimyd/test.txt
<applet code=AppletTest width=200 height=100>
<PARAM NAME = CODE VALUE = AppletTest >
CODE = AppletTest
<APPLET CODE = AppletTest WIDTH = 200 HEIGHT = 100>
- Button/상욱 . . . . 4 matches
public class Test extends JFrame implements ActionListener
public Test() {
super("Test");
JFrame f = new Test();
- Button/영동 . . . . 4 matches
public class JOptionPaneTest extends JFrame implements ActionListener {
public JOptionPaneTest() {
super("JOptionPaneTest");
JFrame f = new JOptionPaneTest();
- ClassifyByAnagram/Passion . . . . 4 matches
== AnagramTest.java ==
package test;
import junit.framework.TestCase;
public class AnagramTest extends TestCase {
public void testOneLine1() throws IOException
public void testOneLine2() throws IOException
public void testTwoLine() throws IOException
public void testGetItemCount() throws IOException
public void testEquals()
public void testContains() throws IOException
public void testContains2() throws IOException
public void testReadFie() throws IOException
public void testParse() throws IOException
- CodeCoverage . . . . 4 matches
CodeCoverage 는 Testing 이 목표 어플리케이션을 얼만큼 충분히 테스트하는가에 대한 측정 지표이다.
CodeCoverage 는 Software Testing 에서 사용하는 측정 도구중의 하나이다. 프로그램이 테스트된 소스 코드의 정도를 기술한다. 이는 다른 대다수의 다른 테스트 메소드와 다른다. 왜냐하면 CodeCoverage 는 소프트웨어 기능, Object interface 과 같은 다른 측정 방법에 비하여 source code를 직접 보기 ㅤㄸㅒㅤ문이다.
See also: RegressionTesting, StaticCodeAnalysis
* http://www.mmsindia.com/JCover.html : Java Test Tool Solution 업체 그중 한 제품
- CxxTest . . . . 4 matches
http://cxxtest.sourceforge.net
C++ 의 경우는 언어차원에서의 리플랙션을 지원하지 않기 때문에 테스트를 추가하는 부분이 자바나 파이썬 등에 비해 상당히 귀찮다. 그에 대한 대안으로 [CUT] 등의 C UnitTestFramework 의 경우 외부에서 Perl 등으로 작성한 스크립트언어로 테스트실행과 관련한 Runner 를 코드제너레이팅하는 방법을 쓰고 있다.
[1002]의 경우 요새 CxxUnit 을 사용중. 밑의 스크립트를 Visual Studio 의 Tools(일종의 External Tools)에 연결시켜놓고 쓴다. Tool 을 실행하여 코드제너레이팅 한뒤, 컴파일. (cxxtestgen.py 는 CxxTest 안에 있다.) 화일 이름이 Test 로 끝나는 화일들을 등록해준다.
testFiles = []
lastestPeriod = eachFile.rfind(".")
fileName = eachFile[:lastestPeriod]
extension = eachFile[lastestPeriod+1:]
if fileName.endswith("Test"):
testFiles.append(eachFile)
'''cmd= "python cxxtestgen.py --runner=ParenPrinter --gui=Win32Gui -o runner.cpp "+toStr(testFiles)'''
cmd= "python cxxtestgen.py --runner=ParenPrinter -o runner.cpp "+toStr(testFiles)
- ErdosNumbers/황재선 . . . . 4 matches
for(int testCase = 0; testCase < scenario; testCase++) {
erdos.printErdosNumber(testCase, name);
Test Code
import junit.framework.TestCase;
public class TestErdosNumbers extends TestCase {
public void testInput() {
public void testPersonName() {
public void testMap() {
latest stable 버전 받으니 되네. 땡쓰~ :) -- 재선
- Hessian . . . . 4 matches
그리고 RPC Test 를 구현해보자. (여기선 Hessian Servlet 을 이용)
public class RpcTest extends HessianServlet implements Basic {
>>> proxy = hessianlib.Hessian("http://localhost:8080/servlet/RpcTest")
String url = "http://localhost:8080/servlet/RpcTest";
- HowManyFibs?/황재선 . . . . 4 matches
== Test Code ==
import junit.framework.TestCase;
public class TestFibonacci extends TestCase {
public void testSample() {
- HowManyZerosAndDigits/임인택 . . . . 4 matches
== {{{~cpp MyTest.java}}} ==
import junit.framework.TestCase;
public class MyTest extends TestCase {
public void testFactorial() {
public void testHowManyZeros() {
public void testNumberSystemConversion() {
- Java/CapacityIsChangedByDataIO . . . . 4 matches
public class CapacityTest {
CapacityTest capacity = new CapacityTest(System.out);
capacity.testStringBuffer();
capacity.testVector();
public CapacityTest(PrintStream anOut) {
public void testStringBuffer() {
public void testVector() {
- JollyJumpers/신재동 . . . . 4 matches
==== JollyJumperTest.java ====
import junit.framework.TestCase;
public class JollyJumperTest extends TestCase {
public void testJollyJumper() {
public void testGetGap() {
public void testJollyJumperTwo() {
public void testJollyJumperThree() {
- JollyJumpers/황재선 . . . . 4 matches
=== TestJollyJumpers.java ===
import junit.framework.TestCase;
public class TestJollyJumpers extends TestCase {
public void testInputNum() {
public void testStringToInt() {
public void testIsRightInput() {
public void testIsJolly() {
3. test코드를 다듬었다. 테스트할때마다 콘솔로 입력받는 게 귀찮아서 test클래스에서 메인 클래스의 field를 정의하고 진행했다. 또 다른 테스트를 하기위해서 고쳐야할 부분이 흩어져 있다. 테스트코드의 설계에 관심을 가져야겠다.
- Memo . . . . 4 matches
import unittest
class TestObserverPattern(unittest.TestCase):
def testUpdate(self):
def testNotify(self):
class TestCompany(unittest.TestCase):
def testCorrectNews(self):
def xtestTwoRepoter(self):
unittest.main(argv=('','-v'))
- MineFinder . . . . 4 matches
* 지뢰찾기 프로그램의 윈도우 핸들을 얻고 해당 메세지를 보내어서 지뢰찾기 프로그램을 구동하는 루틴 관련 SpikeSolution. (아.. UnitTest 코드 넣기가 애매해서 안넣었다. 궁리해봐야 할 부분같다.)
* 지금쯤 다시 짜라고 한다면 TFP를 좀 더 제대로 추구할 수 있을 것도 같다. (이 점에서 TFP를 할때 SpikeSolution 에 대한 어느정도의 충분한 시간을 두는 점이 좋을 것 같다는 생각이 들었다. 초기 SpikeSolution 으로 해당 부분을 간단하게 대강 해보고, Test를 할 수 있는 부분에 대한 구체화하기.)
* CppUnit - 이번 플밍때 윈도우 메세지 관련 처리에 대해서는 코드를 작성못했다. (이 부분에 대해서는 전통적인 Manual Test방법을 쓸 수 밖에. GUI Testing 관련 글을 더 읽어봐야 겠다. 아직 더 지식이 필요하다.) 단, 나중에 비트맵 분석부분 & Refactoring 시에 TFP 를 할 수 있게 되었다.
- MineSweeper/Leonardong . . . . 4 matches
import unittest
class MineSweeperTestCase(unittest.TestCase):
def test3x5example(self):
def testComputeMineCount(self):
class MineGroundTestCase(unittest.TestCase):
def testGetZone(self):
## unittest.main()
- MineSweeper/황재선 . . . . 4 matches
=== {{{~cpp TestMineSweeper.java}}} ===
import junit.framework.TestCase;
public class TestMineSweeper extends TestCase {
public void testFirstLine() {
- ProjectPrometheus/AT_RecommendationPrototype . . . . 4 matches
import unittest
class TestCustomer(unittest.TestCase):
def testOne(self):
class TestRecommendationSystem(unittest.TestCase):
def testHeavyReviewSmall(self):
def testHeavyReviewBig(self):
def testLightReviewBig(self):
def testLightReviewSmall(self):
def testViewBook(self):
def testViewSmall(self):
def testViewBig(self):
def testVLH(self):
def testRecommendationBookList(self):
def testRecommendationBookListBig(self):
def testRecommendationBookListLimitScore(self):
def testRecommendationBookListLimitScoreMore(self):
unittest.main(argv=('', '-v'))
- ProjectPrometheus/CookBook . . . . 4 matches
Statement stmt = conn.createStatement();
=== ZeroPageServer 에서 UnitTest ===
ZeroPageServer 에 릴리즈 한뒤 UnitTest 하기.
.../Prometheus$ java -cp "$CLASSPATH:./bin" junit.textui.TestRunner org.zeropage.prometheus.test.AllAllTests
OK (72 tests)
- STLErrorDecryptor . . . . 4 matches
Test.cpp
h:\MyProgrammingLab\JunkRoom\Weired_C++\Test.cpp(6) :
Test.cpp
h:\MyProgrammingLab\JunkRoom\Weired_C++\Test.cpp(6):
- SeminarHowToProgramIt . . . . 4 matches
* TestDrivenDevelopment -- 프로그래밍의 코페르니쿠스적 전환
||TestDrivenDevelopment || 5 ||
(See Also ["PyUnit"], ["UnitTest"], ["JUnit"], ["CppUnit"]. C 언어를 사용하시는 분들은 ASSERT 문으로 UnitTest 부분을 어느정도 대신할 수 있습니다.)
- SeminarHowToProgramIt/Pipe/vendingmachine.py . . . . 4 matches
import unittest
class TestVendingMachine(unittest.TestCase):
def testPutCoin(self):
def testPushButtonTrue(self):
def testPushButtonFalse(self):
def testRejectLever(self):
def testReset(self):
class TestVendingMachineVerification(unittest.TestCase):
def testVerifyCoinFalse(self):
def testVerifyButtonTrue(self):
def testVerifyButton(self):
def testVerifyCoinTrue(self):
def testVerifyDispenserTrue(self):
def testVerifyDispenserFalse(self):
unittest.main()
- TestDrivenDevelopmentByExample . . . . 4 matches
* http://groups.yahoo.com/group/testdrivendevelopment/ - 야후 그룹.
* http://groups.yahoo.com/group/testdrivendevelopment/files/ - TestDrivenDevelopmentByExample 문서. (아직 미완성중. 계속 업데이트 되고 있습니다. 최신 버전을 받으세요.)
["Java"] 소스(국내에 인기있는;)로 되어있으니 추후 출판뒤 번역이 되지 않을까 하는 희망을; 하지만 지금 진행중인 책의 앞부분을 읽어보긴 했는데. 정말 'Test 로 Driven' 되는 것 같은 느낌이 듬. TDD 진행과정을 예제 하나를 통해 계속 보여주기 때문에 이해하기 편합니다.
TestDrivenDevelopment 에 관심있는사람은 필독문서이겠죠? --["1002"]
See Also Moa:TestDrivenDevelopmentByExample,
- XpWeek/ToDo . . . . 4 matches
고객 - AcceptanceTest 작성
PairProgramming + TestDrivenDevelopment
==== 고객 - AcceptanceTest 작성 ====
모든 AcceptanceTest 통과
- ZP&COW세미나 . . . . 4 matches
* Test-Driven Development by Example, Kent Beck, Addison-Wesley
=== Python Unit Test 예제 ===
import unittest
class AppleTest(unittest.TestCase):
def testTimes(self):
unittest.main()
- radiohead4us/SQLPractice . . . . 4 matches
16. Find all customers who have both an account and a loan at the bank. (4.6.3 Test for Empty Relations)
17. Find all customers who have an account at all the branches located in Brooklyn. (4.6.3 Test for Empty Relations)
18. Find all customers who have at most one account at the Perryridge branch. (4.6.4 Test for the Absence of Duplicate Tuples)
19. Find all customers who have at least two accounts at the Perryridge branch. (4.6.4 Test for the Absence of Duplicate Tuples)
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/강소현,구자경 . . . . 4 matches
import org.junit.Test;
@Test
public void testElevator() {
import org.junit.Test;
@Test
public void testElevator() {
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/송지원,성화수 . . . . 4 matches
== mainTest.java ==
import org.junit.Test;
public class mainTest {
@Test
public void test() {
- 데블스캠프2011/둘째날/Machine-Learning/NaiveBayesClassifier/변형진 . . . . 4 matches
Tester tester = new Tester(new Trainer[] {
new BufferedReader(new FileReader("package/test/economy/economy.txt")),
new BufferedReader(new FileReader("package/test/politics/politics.txt")) };
if (tester.getWeight(i, line) > 0) {
public class Tester {
public Tester(Trainer[] trainers) {
- 몸짱프로젝트/BinarySearchTree . . . . 4 matches
import unittest
class BinartSearchTreeTestCase(unittest.TestCase):
def testMakeChildren(self):
def testSearch(self):
def testInsert(self):
## def testGetNumofChildren(self):
def testGetSingleChild(self):
def testReplace(self):
def testGetLargest(self):
def testDelete(self):
unittest.main()
import unittest
class BinartSearchTreeTestCase(unittest.TestCase):
def testMakeChildren(self):
def testSearch(self):
def testInsert(self):
def testDelete(self):
unittest.main()
- 이승한/질문 . . . . 4 matches
void Test(int * Ascores)
Test(scores);
void Test(int *aArray, int aLength)
Test(scores, arrayLength);
- 2002년도ACM문제샘플풀이/문제A . . . . 3 matches
int numberOfTestCase =0;
cin >> numberOfTestCase;
for ( int testCaseNum=0;testCaseNum<numberOfTestCase;testCaseNum++){
- Ant/BuildTemplateExample . . . . 3 matches
<project name="TestAnt(Ant Project 이름)" default="dist" basedir=".">
<!-- ${build} 디렉토리 안의 class 화일들을 /dist/TestAnt.jar 화일로 묶음. -->
<jar jarfile="${dist}/TestAnt.jar" basedir="${build}"/>
- Ant/JUnitAndFtp . . . . 3 matches
만일 XP Process 를 따른다면, 전체 CustomerTest(AcceptanceTest) 갯수 / 통과하는 Test 갯수 등이 나오므로, 매번 작업의 진척도를 파악하기 쉽다.
<property name="ftptestreportpath" value="/1002/web/htmlreport"/>
<target name="unittest" depends="compile">
<batchtest fork="yes" todir="${report}">
</batchtest>
<include name="TEST-*.xml"/>
<target name="reporttoftp" depends="unittest">
action="del" remotedir="${ftptestreportpath}">
action="mkdir" remotedir="${ftptestreportpath}"/> -->
action="put" remotedir="${ftptestreportpath}">
- AntTask . . . . 3 matches
<project name="TestAnt(Ant Project 이름)" default="dist" basedir=".">
<!-- ${build} 디렉토리 안의 class 화일들을 /dist/TestAnt.jar 화일로 묶음. -->
<jar jarfile="${dist}/TestAnt.jar" basedir="${build}"/>
- BoaConstructor . . . . 3 matches
4. 재사용될 것 같은 모듈들에 대해 UnitTest 를 붙여나간다. 추후 추출용.
UnitTest 가 있는 것만으로도 언제든지 리팩토링할 수 있다는 믿음이 있다면..~ 혼자서 프로토타입 플밍 할때는 그냥 StepwiseRefinement & UnitTest 조합도 괜찮은 것 같다. 빨리 기능을 얻은뒤 기능들 보고 중간에 CRC 해가면서 유용할만한 Object들을 추출해나가는 것도. 언제든지 Object 뽑아낼 자신이 있으니까.
- Button/진영 . . . . 3 matches
// ButtonTest.java
setTitle("ButtonTest");
public class ButtonTest
- CarmichaelNumbers/문보창 . . . . 3 matches
bool passFermatTest(int a, int n);
if (!passFermatTest(i, n))
bool passFermatTest(int a, int n)
- Counting/황재선 . . . . 3 matches
import junit.framework.TestCase;
public class TestCounting extends TestCase {
public void testOne() {
public void testTwo() {
public void testThree() {
public void testFour() {
public void testFive() {
public void testMax() {
- CubicSpline/1002 . . . . 3 matches
* Python 코드에 대한 이해. UnitTest, TestFirstProgramming 에 대한 이해.
=== UnitTest Code ===
* ["CubicSpline/1002/test_lu.py"]
* ["CubicSpline/1002/test_tridiagonal.py"]
* ["CubicSpline/1002/test_NaCurves.py"]
- FreechalAlbumSpider . . . . 3 matches
처음에는 모듈에 대해 Remote Test 를 먼저 진행했다가, Local Test 로서 일단 HTML 문서를 받아놓고, 이를 TDD 로 하면서 데이터들을 추출하는것이 낫겠다 판단, Local Html Test 를 작성해나갔다. 이전 ProjectPrometheus 에서 했었던 방법과 비슷했었던지라, 일사천리로 거의 하루동안 관련 작업들이 끝났다.
- FromDuskTillDawn/조현태 . . . . 3 matches
int numberOfTestCase = 0;
sscanf(readData, "%d", &numberOfTestCase);
for (register int i = 0; i < numberOfTestCase; ++i)
- JollyJumpers/임인택 . . . . 3 matches
public String testify() {
System.out.println(jj.testify());
import junit.framework.TestCase;
public class TestJJ extends TestCase {
public void test배열넣기() {
public void test임시플래그배열크기() {
public void test임시플래그채우기() {
public void testJollyJumpers() {
assertEquals("Jolly", jj.testify());
assertEquals("NotJolly", jj.testify());
public String testify() {
- ProgrammingPearls/Column5 . . . . 3 matches
=== A Test Harness ===
=== Automated Test ===
* Testing : 큰 시스템보다는 발판 내에서 테스트하는게 훨씬 쉽다.
- ProjectZephyrus/ClientJourney . . . . 3 matches
* TDD 가 아니였다는 점은 추후 모듈간 Interface 를 결정할때 골치가 아파진다. 중간코드에 적용하기 뭐해서 궁여지책으로 Main 함수를 hard coding 한뒤 ["Refactoring"] 을 하는 스타일로 하긴 하지만, TDD 만큼 Interface가 깔끔하게 나오질 않는다고 생각. 차라리 조금씩이라도 UnitTest 코드를 붙이는게 나을것 같긴 하다. 하지만, 마감이 2일인 관계로. -_- 스펙 완료뒤 고려하던지, 아니면 처음부터 TDD를 염두해두고 하던지. 중요한건 모듈자체보다 모듈을 이용하는 Client 의 관점이다.
* 5분간격으로 Pair Programming을 했다.. 진짜 Pair를 한 기분이 든다.. Test가 아닌 Real Client UI를 만들었는데, 하다보니 Test때 한번씩 다 해본거였다.. 그런데 위와 아래에 1002형이 쓴걸 보니 얼굴이 달아오른다.. --;; 아웅.. 3일전 일을 쓰려니 너무 힘들다.. 일기를 밀려서 쓴기분이다.. 상상해서 막 쓰고싶지만 내감정에 솔직해야겠다.. 그냥 생각나는것만 써야지.. ㅡ.ㅡ++ 확실히 5분간격으로 하니 속도가 배가된 기분이다.. 마약을 한상태에서 코딩을 하는 느낌이었다.. 암튼 혼자서 하면 언제끝날지 알수없고 같이 해도 그거보단 더 걸렸을듯한데, 1시간만에 Login관련 UI를 짰다는게 나로선 신기하다.. 근데 혼자서 나중에 한 Tree만들땐 제대로 못했다.. 아직 낯선듯하다. 나에게 지금 프로젝트는 기초공사가 안된상태에서 바로 1층을 올라가는 그런거같다.. 머리속을 짜내고있는데 생각이 안난다 그만 쓰련다.. ㅡㅡ;; - 영서
- PythonLanguage . . . . 3 matches
* TestFirstProgramming, UnitTest(PyUnit 참고), ["Refactoring"] 등의 방법론을 같이 접목시키면 더욱 큰 효과를 발휘할 수 있다.
* [GuiTestingWithWxPython]
- RandomWalk/ExtremeSlayer . . . . 3 matches
RandomWalkBoard Test(nRow, nCol, nCurRow, nCurCol);
Test.StartMovement();
Test.ShowBoardStatus();
- Self-describingSequence/황재선 . . . . 3 matches
import junit.framework.TestCase;
public class TestDescribingSequence extends TestCase {
public void testBasic() {
public void testAfter() {
public void testSample() {
- TestDrivenDatabaseDevelopment . . . . 3 matches
import junit.framework.TestCase;
public class SpikeRepositoryTest extends TestCase {
public void testEdit() throws SQLException {
public void testTotalArticle() throws SQLException {
public void testCreateArticle() throws SQLException {
public void testDelete() throws SQLException {
public void testGet() throws SQLException {
public void testArticleTableInitialize() throws ClassNotFoundException, IllegalAccessException, InstantiationException, SQLException {
public void testDuplicatedInitialize() throws ClassNotFoundException, InstantiationException, IllegalAccessException, SQLException {
- TugOfWar/강희경 . . . . 3 matches
def InputTestCaseNumber():
n = input('TestCaseNumber: ')
testCaseNumber = InputTestCaseNumber()
for i in range(0, testCaseNumber):
- VendingMachine/재니 . . . . 3 matches
''클래스 수가 많아서 복잡해진건 아닌듯(모 VendingMachine 의 경우 Requirement 변경에 따라 클래스갯수가 10개 이상이 되기도 함; 클래스 수가 중요하다기보다도 최종 완료된 소스가 얼마나 명료해졌느냐가 복잡도를 결정하리라 생각). 단, 역할 분담할때 각 클래스별 역할이 명료한지 신경을 쓰는것이 좋겠다. CoinCounter 의 경우 VendingMachine 안에 멤버로 있어도 좋을듯. CRC 세션을 할때 클래스들이 각각 따로 존재하는 것 같지만, 실제론 그 클래스들이 서로를 포함하고 있기도 하거든. 또는 해당 기능을 구현하기 위해 다른 클래스들과 협동하기도 하고 (Collaboration. 실제 구현시엔 다른 클래스의 메소드들을 호출해서 구현한다던지 식임). 역할분담을 하고 난 다음 모의 시나리오를 만든뒤 코딩해나갔다면 어떠했을까 하는 생각도 해본다. 이 경우에는 UnitTest 를 작성하는게 좋겠지. UnitTest 작성 & 진행에 대해선 ["ScheduledWalk/석천"] 의 중반부분이랑 UnitTest 참조.--["1002"]''
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/권순의,김호동 . . . . 3 matches
== App.java (Test) ==
import org.junit.Test;
@Test
public void testElevator() {
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/정의정,김태진 . . . . 3 matches
== Test Case ==
import org.junit.Test;
@Test
public void testElevator() {
- 레밍즈프로젝트/프로토타입/파일스트림 . . . . 3 matches
|| Open || Safely opens a file with an error-testing option. ||
if(!Wfile.Open("TestFile.txt", CFile::modeCreate | CFile::modeWrite))
::MessageBox(NULL, "Can't Create testfile.txt !", "Warning", MB_OK | MB_ICONHAND);
if(!Rfile.Open("TestFile.txt", CFile::modeRead))
::MessageBox(NULL, "Can't Open testfile.txt !", "Warning",
파일 입출력 부분에 의해 "TestFile.txt"라는 파일을 만들고,
- 몸짱프로젝트/CrossReference . . . . 3 matches
* 개발방식 : TestDrivenDevelopment
import unittest
class CrossReferenceTestCase(unittest.TestCase):
## def testFind(self):
def testGetNode(self):
def testSetNode(self):
unittest.main()
- 지금그때2003/규칙 . . . . 3 matches
==== Simple Rule Test ====
a. 선호, 인수, 상민 Seminar:SimpleRule Test 금요일 1시간 동안 진행 (V)
* Test 중 2번의 룰을 좀더 완화 하였다. 경험을 붙이니 말에 너무 많은 제약사항이 붙었다. 그래서 우리는 한가지 제약사항을 없애고, '''제가, 저는, 저도'''로 룰을 바꾸어 해보았는데, 자신을 낮추는 것만으로 원만한 대화의 장이 될수 있었다.
- 5인용C++스터디/마우스로그림그리기 . . . . 2 matches
|| 조재화 || UploadZero:Test_2.zip|| 잘했음. ||
|| 조재화 || Upload:TestPenTool.zip || 잘했음. ||
- Android/WallpaperChanger . . . . 2 matches
package june.my.testdroid;
public class TestdroidActivity extends Activity {
|| 4/10 || Test버전 WallpaperChanger작동 ||
- ClassifyByAnagram/박응주 . . . . 2 matches
상대 속도 약 1.35. test2와 test3의 간격이 너무 크다. 작성하는데 얼마나 걸리는 지 또 안재어봤다. :(
import unittest
class AnagramTestCase(unittest.TestCase):
def test1(self):
def test2(self):
def test3(self):
#unittest.main(argv=('', '-v'))
- ClassifyByAnagram/재동 . . . . 2 matches
import unittest
class AnagramTestCase(unittest.TestCase):
def testCreationAnagram(self):
def testSplitWord(self):
def testSortWord(self):
def testIsWordListInAnagramList(self):
def testStoreWord(self):
def testAcceptence(self):
#unittest.main()
- ConstructorMethod . . . . 2 matches
개인적으로는 JUnit Test 작성할때, Test 대상이 되는 클래스에 대한 리팩토링 시도하는중 중간단계 역할로 많이 써먹었음.
- CubicSpline/1002/test_lu.py . . . . 2 matches
import unittest
class TestLuDecomposition(unittest.TestCase):
def testLwrite(self):
def testUwrite(self):
def testLuDecMore(self):
def testLuDecomposition(self):
unittest.main()
- CubicSpline/1002/test_tridiagonal.py . . . . 2 matches
import unittest
class TestTridiagonal(unittest.TestCase):
def testGetMatrixY(self):
def testGetMatrixX(self):
unittest.main()
- EasyJavaStudy . . . . 2 matches
* ["Java"], ["Eclipse"], ["JUnit"], ["TestDrivenDevelopment"], ["TestFirstProgramming"]
- Eclipse . . . . 2 matches
* [neocoin]:정말 Java Source Editor면에서는 이것보다 나은것을 찾지 못하겠다. CVS 지원 역시 훌륭하고, Project파일 관리 면에서도 우수하다. 하지만 가장 인상 깊었던건 오픈 프로젝트라서, 이걸 볼수 있다는 점이다. 바로 [http://64.38.198.171/downloads/drops/R-2.0-200206271835/testResults.php org.eclipse.core.tests] 이런것을 각 분야별로 수백개씩 하고 있었다. 이런것은 나에게 힘을 준다. --상민
* 기능으로 보나 업그레이드 속도로 보나 또하나의 Platform; 플러그인으로 JUnit 이 아에 들어간것과 리펙토링 기능, Test Case 가 new 에 포함된 것 등 TDD 에서 자주 쓰는 기능들이 있는건 반가운사항. (유난히 자바 툴들에 XP 와 관련한 기능들이 많이 추가되는건 어떤 이유일까. MS 진영에 비해 자바 관련 툴의 시장이 다양해서일까) 아주 약간 아쉬운 사항이라면 개인적으로 멀티 윈도우 에디터라면 자주 쓸 창 전환키들인 Ctrl + F6, Ctrl + F7 은 너무 손의 폭 관계상 멀어서 (반대쪽 손이 가기엔 애매하게 가운데이시고 어흑) ( IntelliJ 는 Alt + 1,2,3,.. 또는 Alt + <- , ->) 단축키들이 많아져 가는 상황에 재정의하려면 끝도 없으시고. (이점에서 최강의 에디터는 [Vi] 이다;) 개인적 결론 : [Eclipse] 는 Tool Platform 이다; --석천
* quick fix, UnitTest, [Refactoring], [CVS], 그리고 방대하고 다양한 플러그인들이 제일 마음에 든다. 툴을 사용하는 재미가 있다. - [임인택]
- EightQueenProblem/Leonardong . . . . 2 matches
import unittest
class EightQueenTestCase(unittest.TestCase):
## def testMakeChessBoard(self):
def testSetQueen(self):
def testIsPositionValid(self):
def testPopLastPosition(self):
def testFindNext(self):
def testRun(self):
unittest.main()
- EightQueenProblem/김형용 . . . . 2 matches
import unittest, random, pdb
class TestEightQueenProblem(unittest.TestCase):
def testIntialPosition(self):
def testRowCheck(self):
def testColumnCheck(self):
def testMakeRightDigTuple1(self):
def testMakeRightDigTuple2(self):
def testMakeRightDigTuple3(self):
def testMakeLeftDigTuple1(self):
def testMakeLeftDigTuple2(self):
def testRightDigCheck(self):
def testTotal(self):
unittest.main(argv=('','-v'))
- ErdosNumbers/임인택 . . . . 2 matches
import unittest
class TestErdos(unittest.TestCase):
def testStripstring(self):
def testInputInfo(self):
def testAllNames(self):
def testErdosNum(self):
#unittest.main(argv=('','-v'))
- ExtremeBear/VideoShop/20021105 . . . . 2 matches
* Test를 쉽게 할수 있는 구조를 만드는것이 어려웠다.
* Test에 걸리는 시간이 더 많았다.
- ExtremeBear/VideoShop/20021106 . . . . 2 matches
* Test 익숙해졌다.
* Test 가 자연스럽고 쉬웠다.
- FromDuskTillDawn . . . . 2 matches
{{| Test Case 1.
Test Case 2.
- IpscLoadBalancing . . . . 2 matches
import unittest, shlex
class TestLoadBalancing(unittest.TestCase):
def testGetRounds(self):
def testParseLine(self):
unittest.main(argv=('','-v'))
- JTDStudy/첫번째과제/장길 . . . . 2 matches
== testcode ==
import junit.framework.TestCase;
public class testBaseball extends TestCase {
public void testDealer(){
public void testPlayer(){
public void testJudgement(){
- JTDStudy/첫번째과제/정현 . . . . 2 matches
public class BaseBallTest extends TestCase{
public void testStrikeCount() {
public void testBallCount() {
public void testNumberCreation() {
public void testDuplicated() {
public void testGamePlay() {
- JavaScript/2011년스터디/김수경 . . . . 2 matches
var initializing = false, fnTest = /xyz/.test(function(){xyz;}) ? /\b_super\b/ : /.*/;
typeof _super[name] == "function" && fnTest.test(prop[name]) ?
- JavaStudy2002 . . . . 2 matches
* ["Java"], ["Eclipse"], ["JUnit"], ["TestDrivenDevelopment"], ["TestFirstProgramming"]
- JavaStudy2004/클래스 . . . . 2 matches
==== TestHello.java ====
public class TestHello {
- JavaStudyInVacation . . . . 2 matches
* ["Java"], ["Eclipse"], ["JUnit"], ["TestDrivenDevelopment"], ["TestFirstProgramming"]
- JollyJumpers/Leonardong . . . . 2 matches
import unittest
class JollyJumperTestCase(unittest.TestCase):
def test12(self):
def test13(self):
def testCheckJolly(self):
def testGetSetOfDiffernce(self):
def testSample(self):
## unittest.main()
- Karma . . . . 2 matches
JavaScript의 Test를 돌려주는 Test Runner.
[http://www.yearofmoo.com/2013/01/full-spectrum-testing-with-angularjs-and-karma.html]
- Linux/배포판 . . . . 2 matches
GNU에 정신에 입각해서 만들어지는 배포판이다. 공식명식 GNU/Debian Linux 이다. 데비안의 이름은 배포자인 이안, 그의 부인 데보라 이름을 땃다고한다. 패키징은 과거 dselect를 이용하였고, 현재는 aptitude 라는 툴을 기반으로 한다. ''(관리정보를 보관하기 때문에 서로 호환성을 갖지는 않는다고 한다.)'' 데비안의 안정판은 대단히 배포사이의 공백기가 긴 것으로 유명하다. 혹자들은 메인테이너들이 굉장히 신중한 사람들이라고 평가하기도 한다. ''(01년도 Woody를 시작으로 05년 Sarge 사이에 딱 하나의 안정판이 있을뿐이다. 대략 2년에 한번꼴이다.)'' 대신에 Stable, Testing, Unstable, Experimental 이라는 단계적 개념으로 패키지를 제공해서 사용자의 선택의 폭을 제공한다. 그렇지만 Unstable 이라고해도 페도라만큼 최신의 패키지들로 묶이지는 않고 어느정도 성숙이 되면 패키지로 포함되는 경우가 다반사이다. 안정적 서버운영을 위해서는 안정판을 설치하는 경우가 많고, 일반용도로는 Testing, Unstable을 설치한다. (www.kldp.org 가 현재 데비안 Sarge-stable 로 운영중이다.) 패키지방식은 의존성에 대한 철저한 관리가 특징이다. 데비안이 유명한 것은 바로 이 패키지 관리의 엄격함 때문이기도 하다. 그렇지만 최신의 기술로 만들어진 소프트를 원하는 이들에겐 그다지 좋은 덕목은 아니다. 네트워크를 통해서 인스톨하기 때문에 base-system 이상의 것들은 네트웍이 연결된 상태에서 설치가 가능하다. 대신에 모든 배포판은 CD1장으로 구성된다. (net-install의 경우 대략 100MB 정도) 현재는 데비안의 엄격한 패키징 방식에서 좀더 유연한 자식격 배포판인 우분투이 나오면서 상당한 인기를 끌고 있다. 우분투는 데스크탑용 OS를 표방하고 발표되어으며, 실제로 CD로 엔터만 누르면서 완전설치가 가능하다.
- LoadBalancingProblem/Leonardong . . . . 2 matches
import unittest
class SuperComputerTestCase(unittest.TestCase):
def testIsComplete(self):
def testShareWork(self):
def testIsThisOverWork(self):
def testRun(self):
unittest.main()
- NSIS/예제3 . . . . 2 matches
ComponentText "Testing ver ${VER_MAJOR}.${VER_MINOR} 설치 합니다. 해당 컴포넌트를 골라주세요~"
Processing script file: "test1.nsi"
ComponentText: "Testing ver 1.0 설치 합니다. 해당 컴포넌트를 골라주세요~" "" ""
- Ones/1002 . . . . 2 matches
import unittest
class OnesTest(unittest.TestCase):
def testSmall(self):
def testSmall2(self):
def testLarge(self):
def testIsAllOne(self):
#unittest.main(argv=('','-v'))
- PNGFileFormat/FormatUnitTestInPythonLanguage . . . . 2 matches
#---------------- pngtest.py -------------------------------------------
import unittest
class TestPngFormat(unittest.TestCase):
def testFirstEightBytes(self):
def testChunkLength(self):
def testImageIHDR(self):
def testImageDataSize(self):
def testRGB(self):
def testCRC(self):
def testPaeth(self):
def testCompareWithPIL(self):
print ' PNG Format TEST'
unittest.main(argv=('', '-v'))
- PrimaryArithmetic/Leonardong . . . . 2 matches
import unittest
class TemplateTestCase(unittest.TestCase):
def testCountUpCarryEqualDegreeOne(self):
def testGetValueOfDegree(self):
def testCountUpCarryEqualDegreeTwo(self):
def testComplex(self):
def testCarry(self):
unittest.main()
- ProgrammingLanguageClass/2006/Report3 . . . . 2 matches
properly by testing it for various summation below.
제시된 문제는 상기와 같으며, 이는 100번째의 조화수를 구하는 문제를 해결하는 방법입니다. 차후에 그 이름도 유명한 Knuth 님께서 Man Boy Test로 발전시켰습니다.
cf) Jensen's Device, Man Boy Test 는 Compiler Theory 의 한 항목들입니다.
required to submit a listing of your program and a set of test data of your own choice,
and its output, when you show up for demo. Be sure to design carefully your test data
- ProjectPrometheus/AcceptanceTest . . . . 2 matches
AcceptanceTest Server - http://zeropage.org/~reset/cgi-bin/AcceptanceTestServer/testserver.cgi
* 테스트들을 testserver.py 에 등록하지 않고 해당 디렉토리내의 모든 테스트들을 찾아서 실행하게끔.
- ProjectPrometheus/EngineeringTask . . . . 2 matches
|| Book Search Acceptance Test 작성 || ○ ||
|| Iteration 2 AcceptanceTest 작성 || ○ ||
- ProjectPrometheus/Iteration4 . . . . 2 matches
|| ["ProjectPrometheus/AcceptanceTestServer"] 작성 || 2 || ○ ||
|| Iteration 1, 2 AcceptanceTest WEB 에서 테스트 가능하도록 연결 || 1 || ○ ||
- ProjectPrometheus/Iteration5 . . . . 2 matches
|| DB Test Data Set 입력 스크립트 작성 || 1 || ○ ||
|| Iteration 3,4 의 Story 들에 대해서 Acceptance Test 작성 || 1 || . ||
- ProjectPrometheus/Iteration9 . . . . 2 matches
* AcceptanceTest 에 대해서는 변함 없음.
-> AcceptanceTest Update
- RandomWalk2 . . . . 2 matches
* ["RandomWalk2/TestCase"]
* ["RandomWalk2/TestCase2"]
- RandomWalk2/ExtremePair . . . . 2 matches
import unittest
class ManTestCase(unittest.TestCase):
def testMakeBoard(self):
def testMakeRoach(self):
def testMoveRoach(self):
def testPierceRoach(self):
def testIsBoardAllPassed(self):
#unittest.main()
- ReverseAndAdd/신재동 . . . . 2 matches
import unittest
class ReverseAndAdderTestCase(unittest.TestCase):
def testReverse(self):
def testIsPalindrome(self):
def testReverseAndAdd(self):
#unittest.main()
''all tests data will be computable with less than 1000 iterations (additions)''를 고려한다면 명시적인 회수 체크는 없어도 될 듯.
- ReverseAndAdd/황재선 . . . . 2 matches
import unittest
class ReverseAndAddTestCase(unittest.TestCase):
def test1(self):
for testcase in range(num):
#unittest.main()
- Server&Client/영동 . . . . 2 matches
public class SimpleServerSocketTest
public class SimpleSocketTest
- SimpleDesign . . . . 2 matches
저 원칙은 XP 와 떼어서 생각하기 힘든, TestDrivenDevelopment 에서 더 제대로 적용된다. TestDrivenDevelopment 를 하면 할수록 가장 단순한 것에 대해서 생각하게 된다. 이번에 기사를 쓰기 위해 간단한 프로그램을 같은 문제에 대해서만 5번 정도 풀어보게 되었는데, 풀 때마다 더 간단한 해결책이 보이게 되고, 문제를 더 잘게 나눌 수 있게 되었다.
- Slurpys/박응용 . . . . 2 matches
import unittest
### test code ##########################################################
class SlurpyTest(unittest.TestCase):
def testWord(self):
def testAnd(self):
def testMore(self):
def testOr(self):
def testSlump(self):
def testSlimp(self):
def testSlurpy(self):
unittest.main(argv=('', '-v'))
- Slurpys/신재동 . . . . 2 matches
import unittest
class SlurpysTestCase(unittest.TestCase):
def testSlump(self):
def testNotSlump(self):
def testSlimp(self):
def testNotSlimp(self):
def testSlurpy(self):
def testNotSlurpy(self):
#unittest.main()
- Slurpys/황재선 . . . . 2 matches
import unittest
class SlurpysTestCase(unittest.TestCase):
def testSlimp(self):
def testSlump(self):
def testSlurpy(self):
#unittest.main(argv=('', '-v'))
- SpiralArray/임인택 . . . . 2 matches
import unittest
class MyTest(unittest.TestCase):
def testNextSeqence(self):
def testRotList(self):
def testArrayCreation(self):
testArr = [[0]*3]*3
self.assertEquals(expected, testArr)
#unittest.main(argv=('','-v'))
- Spring/탐험스터디/2011 . . . . 2 matches
1.2. MySQL 실행 후 test 테이블 선택. 책의 예제대로 users를 만든다.
1.4. Connection c = DriverManager.getConnection(...); 문장에서 에러가 나는데 문자열의 localhost/springbook 부분을 자신이 사용할 테이블의 이름으로 바꾸어 주어야 한다. localhost/test로 바꿔준다. 이후의 문자열 두 개는 각각 자신의 MySQL 계정 이름(기본값 root), MySQL 비밀번호를 적어주면 된다.
at springbook.user.dao.UserDaoTest.main(UserDaoTest.java:13)
- SummationOfFourPrimes/1002 . . . . 2 matches
class PrimeNumberTest(unittest.TestCase):
def testPrimeNumber(self):
#unittest.main(argv=('','-v'))
- TddWithWebPresentation . . . . 2 matches
http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/test_viewpageaction.py?rev=1.2&content-type=text/plain
즉, 일종의 Template Method 의 형태로서 Testable 하기 편한 ViewPageAction 의 서브클래스를 만들었다. 어차피 중요한것은 해당 표현 부분이 잘 호출되느냐이므로, 이에 대해서는 서브클래스로서 텍스트를 비교했다.
http://free1002.nameip.net:8080/viewcvs/viewcvs.cgi/*checkout*/pyki/test_viewpageaction.py?rev=1.3&content-type=text/plain
하지만, 이건 리팩토링 단계에서의 이야기고, 만일 새 코드를 작성하는 중의 UI 부분 presenter 를 TDD로 구현한다면 어떻게 될까? 아마 저 MockViewPresenter 부분이 먼저 구현되고, 이 인터페이스를 근거로 ViewPresenter 를 만든 뒤 HTML 코드 부분을 작성하면 될 것 같다. 실제 UI 에 어떠어떠한 것이 표현되느냐는 AcceptanceTest 단에 맡기면 되리라.
1. action test 를 만든다. (생각해보건데, action 에서의 Servlet 부분이 있는 곳 또한 얇게 만들 수 있겠다는 생각을 해본다.)
- TheJavaMan . . . . 2 matches
* [Java], [Eclipse], [JUnit], TestDrivenDevelopment, TestFirstProgramming
- TheTrip/Leonardong . . . . 2 matches
import unittest
class TheTripTestCase(unittest.TestCase):
def testGetListOfBiggerThan(self):
def testOfferAShareOfMoney(self):
unittest.main()
- UglyNumbers/황재선 . . . . 2 matches
import unittest
class UglyNumbersTestCase(unittest.TestCase):
def testFindUglyNumber(self):
#unittest.main()
- VonNeumannAirport . . . . 2 matches
* ["1002"] 의 개인적으로 생각되는 '미숙' 했다고 생각한 점을 든다면, 평소에 프로그래밍을 하는 리듬이 아니였다는 점. 이전 스타일이라면 일단 문제를 보고 문제를 나누면서 시나리오를 어느정도 만들어 놓은 뒤, 그걸 검증해나간다는 느낌으로 테스트코드를 작성했었는데, 이번의 경우 정말 Extreme 하게 작업한 것 같다. (중반에 CRC 라도 한번 하고 싶었는데, 형에게 물어보고 왠지 '아 내가 알던 방법이 틀린걸꺼야' 하며 그냥 Test 만 생각하게 되었다.) 작업하는 중간 뭔가 석연치 않은 느낌이 들었다면, 아마 대강 이런 느낌이였던 것 같다. 전반적 시각을 한번정도 중간에 정리를 할 필요가 있을건데, 그런 시간을 두지 못한것.
Requirement 수정 예상궁리 (일단은 떠오르는대로. Testability 를 고려하지 않은 상태로)
- VonNeumannAirport/Leonardong . . . . 2 matches
import unittest
class TestDistance(unittest.TestCase):
def testOneToOneDistance(self):
def testReversalDistance(self):
def testTraffic(self):
def testTotal(self):
def testReal(self):
unittest.main()
- WeightsAndMeasures/황재선 . . . . 2 matches
import unittest
class WeightsAndMeasuresTestCase(unittest.TestCase):
def testInputEachData(self):
def testPutInStack(self):
def testFindNextDataIndex(self):
def testNext(self):
def testOneData(self):
def testOneData2(self):
def testOneData3(self):
## unittest.main()
- WikiSandBox . . . . 2 matches
test
Test -- [ucyang] [[DateTime(2021-08-05T06:03:17)]]
Test -- [ucyang] [[DateTime(2021-08-05T06:03:33)]]
- cookieSend.py . . . . 2 matches
ef zeropageCookieTest():
httpData = getResponse(host="zeropage.org", webpage="/~reset/testing.php", method='GET', paramDict=params, cookieDict=cookie)
zeropageCookieTest()
- erunc0/PhysicsForGameDevelopment . . . . 2 matches
=== ParticleTest ===
* Release - http://zp.cse.cau.ac.kr/~erunc0/study/physics/Particle_Test.exe
- java/reflection . . . . 2 matches
public class TestReflection {
ClassLoader classLoader = TestReflection .class.getClassLoader();
- 금고 . . . . 2 matches
=== Extra Test Input ===
=== Extra Test Output ===
- 데블스캠프2011/다섯째날/HowToWriteCodeWell/박정근,김수경 . . . . 2 matches
import org.junit.Test;
@Test
public void testElevator(){
//Elevator가 생성되었는지 test한다.
- 만년달력/김정현 . . . . 2 matches
public class TestCalendar extends TestCase{
public void testDayCount() {
public void testActualDaycount() {
public void testAcutalDayCountInYear() {
public void testTotalDays() {
public void testDayName() {
public void testInitialMaker() {
public void testMakingCarendar() {
- 몸짱프로젝트/InfixToPrefix . . . . 2 matches
import unittest
class ExpressionConverterTestCase(unittest.TestCase):
def testGetPrecedence(self):
def testIsOperator(self):
def testGetConvertedExpression(self):
def testPutToken(self):
def testPutOperator(self):
def testConvertInfixToPrefix(self):
unittest.main()
- 숫자를한글로바꾸기 . . . . 2 matches
* 이강성 교수님께서 만드신 TestDrivenDevelopment 강의 동영상에서 다룬 내용과 같은 문제네요. 이 문제를 푸신 분들은 제게 메신저로 말씀을 해 주세요. DevilsCamp 때도 TestDrivenDevelopment 에 대해서 잠깐 접해보셨겠지만 이 동영상을 보시면 많은것을 얻으실 수 있을 것 같네요. 참고로 제 MSN 주소는 boy 골뱅 idaizy.com 입니다. 원저자께서 해당 파일이 무작위적으로 유포되는걸 원치 않으셔서 신청자에 한해서만 파일을 보내드리겠습니다. - 임인택
- 실시간멀티플레이어게임프로젝트 . . . . 2 matches
import unittest
class CalculatorTestCase(unittest.TestCase):
def testPlus(self):
unittest.main()
- 정모/2002.5.30 . . . . 2 matches
* PairProgramming 에 대한 오해 - 과연 그 영향력이 '대단'하여 PairProgramming을 하느냐 안하느냐가 회의의 관건이 되는건지? 아까 회의중에서도 언급이 되었지만, 오늘 회의 참석자중에서 실제로 PairProgramming 을 얼마만큼 해봤는지, PairProgramming 을 하면서 서로간의 무언의 압력을 느껴봤는지 (그러면서 문제 자체에 대해 서로 집중하는 모습 등), 다른 사람들이 프로그래밍을 진행하면서 어떠한 과정을 거치는지 보신적이 있는지 궁금해지네요. (프로그래밍을 하기 전에 Class Diagram 을 그린다던지, Sequence Diagram 을 그린다던지, 언제 API를 뒤져보는지, 어떤 사이트를 돌아다니며 자료를 수집하는지, 포스트잎으로 모니터 옆에 할일을 적어 붙여놓는다던지, 인덱스카드에 Todo List를 적는지, 에디트 플러스에 할일을 적는지, 소스 자체에 주석으로 할 일을 적는지, 주석으로 프로그램을 Divide & Conquer 하는지, 아니면 메소드 이름 그 자체로 주석을 대신할만큼 명확하게 적는지, cookbook style 의 문서를 찾는지, 집에서 미리 Framework 를 익혀놓고 Reference만 참조하는지, Reference는 어떤 자료를 쓰는지, 에디터는 주로 마우스로 메뉴를 클릭하며 쓰는지, 단축키를 얼마만큼 효율적으로 이용하는지, CVS를 쓸때 Wincvs를 쓰는지, 도스 커맨드에서 CVS를 쓸때 배치화일을 어떤식으로 작성해서 쓰는지, Eclipse 의 CVS 기능을 얼마만큼 제대로 이용하는지, Tool들에 대한 정보는 어디서 얻는지, 언제 해당 툴에 대한 불편함을 '느끼는지', 문제를 풀때 Divide & Conquer 스타일로 접근하는지, Bottom Up 스타일로 접근하는지, StepwiseRefinement 스타일를 이용하는지, 프로그래밍을 할때 Test 를 먼저 작성하는지, 디버깅 모드를 어떻게 이용하는지, Socket Test 를 할때 Mock Client 로서 어떤 것을 이용하는지, 플밍할때 Temp 변수나 Middle Man들을 먼저 만들고 코드를 전개하는지, 자신이 만들려는 코드를 먼저 작성하고 필요한 변수들을 하나하나 정의해나가는지 등등.)
- 주민등록번호확인하기/문보창 . . . . 2 matches
==== {{{~cpp TestSocialNuber.java}}} ====
public class TestSocialNumber
- 지도분류 . . . . 2 matches
|| CodeCoverage || 작성한 Test 가 Code 를 얼마나 수용하나 검사해주는 도구들 ||
|| RegressionTesting || 회귀 테스팅으로 기존의 기능에 문제 없는가 테스트 ||
- 최소정수의합/임인택 . . . . 2 matches
import unittest
class TestMinInt(unittest.TestCase):
def testSummation(self):
#unittest.main(argv=('','-v'))
- 캠이랑놀자/아영 . . . . 2 matches
print "Testing..."
print "Testing..."
- 프로그래밍파티 . . . . 2 matches
ZP 랑 Moa 랑 페이지가 따로 열려있어서 정보가 분산되는 느낌이 드는데, 한곳에서 토의하는건 어떨까요? 그리고 DesignFest랑 ProgrammingContest 중 어떤거 할것인가는 무기명투표모드를 함 적용하는것도..~ (ProgrammingContest 의 경우 IPSC로 ZP가 예습(?)한 것 같은 느낌이 들어서;; 오 찔린다;) 14일까지 결정하고, 16일까지 행사때 진행방법을 구체적으로 정했으면 합니다.~ ^^ --석천
* Testability & Test coverage : 테스트가능성과 테스트지원 정도
- 1thPCinCAUCSE/ExtremePair전략 . . . . 1 match
* ["TestDrivenDevelopment"]를 사용했다고 말하기는 그렇지만 테스트 케이스를 입력으로 넣어놓고 프로그래밍 중간 중간에 제대로 돌아가는 지를 확인하기 위해 지금까지의 진행 상황을 출력했습니다.
- 1thPCinCAUCSE/null전략 . . . . 1 match
한 20분정도 잘못진행했었는데, 첫번째는 ["1002"] 가 B 번문제를 제대로 이해하지 못했고 (앞부분만 읽고, 문제의 input-output 을 거꾸로 판단), 두번째는 input 이 100 일때의 output 예상치를 잘못계산한 상태에서 이를 근거로 Test Driven 을 시도해서 추후 발견뒤 테스트를 수정하는동안 시간을 낭비했습니다.
- 2002년도ACM문제샘플풀이/문제E . . . . 1 match
* {{{~cpp TestCase}}}를 살펴보다 보니, 열라 어이없는 규칙을 발견하고 맘.
- 2005MFC이동현님의명강의 . . . . 1 match
Upload: Test01.zip
- 2010JavaScript/강소현/연습 . . . . 1 match
<title>Event Test</title>
- 2학기파이선스터디/문자열 . . . . 1 match
5. 멤버십 데스트(Membership Test) = in
- 3DAlca . . . . 1 match
* 현재 Tested by 정현, 재동
- 5인용C++스터디/다이얼로그박스 . . . . 1 match
이 부분에서 사용자가 선택하고 싶은 것을 선택을 한다. 이 Test프로그램은 Dialog based를
- 5인용C++스터디/작은그림판 . . . . 1 match
|| 조재화 || Upload:TestPenTool_0.1.zip || 잘했음. ||
- APlusProject . . . . 1 match
TestDrivenDevelopmentByExample - TDD 입문서. 한서 있음. QA와 Eng는 필독.
- ATmega163 . . . . 1 match
== 웨비 사운드에서 구한 ATmega 163 L 보드에 관한 Testing ==
* 전원 어뎁터를 연결하면 LED가 켜지며 TEST를 위한 준비는 끝난다.
-- WAVY SOUND XXXXXX TEST --- 란 식의 명령어가 뜬다. 그럼 하드웨어 TEST 완료
TRG = test
- AcceleratedC++/Chapter3 . . . . 1 match
=== 3.1.1 Testing for end of input ===
- Ant . . . . 1 match
% ant -buildfile test.xml
이것은 build 파일을 test.xml 이라는 파일을 build 파일로 사용해서 build 하겠다는 의미입니다.
% ant -buildfile test.xml dist
% ant -buildfile test.xml -Dbuild=build/classes dist
* [http://developer.java.sun.com/developer/Quizzes/misc/ant.html Test your knowledge of Ant]
- BarMacro . . . . 1 match
||Test Task||[[DueDate(20311121)]]||
- BasicJAVA2005 . . . . 1 match
질문 !! 이클립스 쓰는데, run as에 이상한 JUnit Plug-in Test 이런거만 있는데, 어떻게 정상적으로 java application 나오게 하죠? -- 허아영
- BasicJAVA2005/실습1/조현태 . . . . 1 match
public class Test001 {
- BookShelf . . . . 1 match
1. [테스트주도개발] - [TestDrivenDevelopmentByExample] 번역서
- CleanCode . . . . 1 match
* Chapter 9 Unit Tests
* [http://oddpoet.net/blog/2010/08/02/a-new-look-at-test-driven-development-kr/ BDD, Given/When/Then]
- CompilerTheory/ManBoyTest . . . . 1 match
= Man Boy Test =
- ConvertAppIntoApplet/영동 . . . . 1 match
public class AppletTest extends JApplet implements ActionListener {
- DelegationPattern . . . . 1 match
이 기능을 추가하기 위해 일단 Airport Code 를 Refactoring 하기로 했다. 이를 위해 Airport 의 기능중 Configuration 과 관련된 기능에 대해 Configuration 을 Extract 하고, 내부적으로는 Delegation 함으로서 외부적으로 보이는 기능에 대해서는 일관성을 유지한다. (Test Code 가 일종의 Guard 역할을 했었음)
- DesignPatternsAsAPathToConceptualIntegrity . . . . 1 match
The following summary is from “Design Patterns as a Litmus Paper to Test the Strength of Object-Oriented Methods” and may provide some insight:
- DoItAgainToLearn . . . . 1 match
Seminar:SoftwareDevelopmentMagazine 에서 OOP의 대가 Uncle Bob은 PP와 TDD, 리팩토링에 대한 기사를 연재하고 있다. [http://www.sdmagazine.com/documents/s=7578/sdm0210j/0210j.htm A Test of Patience]라는 기사에서는 몇 시간, 혹은 몇 일 걸려 작성한 코드를 즐겁게 던져버리고 새로 작성할 수도 있다는 DoItAgainToLearn(혹은 {{{~cpp DoItAgainToImprove}}})의 가르침을 전한다.
- EffectiveC++ . . . . 1 match
void assignmentTester()
- Favorite . . . . 1 match
[http://groups.yahoo.com/group/testdrivendevelopment/ TDD 야후그룹]
[http://xper.org/wiki/xp/TestDrivenDevelopmentInCeeLanguage TDD in Cee]
- FromDuskTillDawn/변형진 . . . . 1 match
echo "Test Case ".($n+1).".<br>";
- HanoiProblem . . . . 1 match
종종 미로가 너무 복잡할 때 목적지에서 거꾸로 내려오는 것이 더 간단할 때가 있습니다. TestDrivenDevelopment도 이 방법을 사용합니다. 자신이 원하는 것을 컴퓨터에게 설명해 주고, 그 목적지에서 거슬러 내려옵니다.
- HowToStudyXp . . . . 1 match
* ["TestDrivenDevelopmentByExample"] (Kent Beck) : 곧(아마 올해 내에) 출간 예정인 최초의 TDD 서적. TDD를 모르면 XP도 모르는 것. (TDD를 실제 적용하려면 적어도 반년 정도는 계속 훈련해야 함)
* http://groups.yahoo.com/group/testdrivendevelopment
* http://groups.yahoo.com/group/agile-testing
- IntelliJ . . . . 1 match
개인적으로 IntelliJ 는 정말 TestDrivenDevelopment 와 Simplicity 를 위한 에디터라고 생각하는데, 이유는 리팩토링 기능이나 화면상 UI (쓰이지 않는 필드 등에 대해선 회색으로 표시됨), 그리고 Inspection 기능때문이다.
자주 쓰는 기능들임에도 불구하고 단축키가 정의되지 않은 기능들이 있다. 특히 run class 와 run test 들이 그러한데, 이들은 Key Map 을 직접 해주도록 하자. (개인적으론 ctrl + F10, shift + ctrl + F10 으로 정의해놓고 씀)
- JTDStudy . . . . 1 match
* [TestDrivenDevelopment]
- Java/ReflectionForInnerClass . . . . 1 match
public class InnerConstructorTest {
- JavaNetworkProgramming . . . . 1 match
public class FilterTest{
protected void writeStreamHeader() throws IOException{
super.writeStreamHeader(); //수퍼클래스의 헤더를 출력한후에
- JavaScript/2011년스터디/윤종하 . . . . 1 match
<head><title>Anonymous Function Test</title></head>
- Jython . . . . 1 match
* [http://huniv.hongik.ac.kr/~yong/MoinMoin/wiki-moinmoin/moin.cgi/JythonTestCode PyUnit 과 Java Class 와의 만남 from 박응용님 위키]
- ListCtrl . . . . 1 match
ListIndex = m_ctrlZoneList.HitTest(Index);
- MFC/Socket . . . . 1 match
temp.m_strData = "TEST2";
data.m_strData = "TEST";
* 그러면 서버쪽에서 TEST 메시지를 받았다는것이 나오고, 그것을 OK 누르면 클라이언트쪽에서 TEST2메시지를 받았다고 나온다.
Upload:OmokSocketTest.zip
- MoinMoinBugs . . . . 1 match
Back to MoinMoinTodo | Things that are MoinMoinNotBugs | MoinMoinTests contains tests for many features
* If you want the ''latest'' diff for an updated page, click on "updated" and then on the diff icon (colored glasses) at the top.
* The intent is to not clutter RecentChanges with functions not normally used. I do not see a reason you want the lastest diff when you have the much better diff to your last visit.
* Not CVS, but versioning all the same. I mean you have to get the most recent code from the SourceForge CVS archive for some features to work, if you test on a ''local'' wiki.
- MoniWikiPlugins . . . . 1 match
* Test /!\ 데모용
- NSIS/Reference . . . . 1 match
|| Section || "ZPTest Defaults Modules (required)" || Section 의 시작을 알린다. Section의 이름을 설정. 만일 Section의 이름이 비어있거나 '-'로 시작되는 경우에는 사용자가 선택할 수 없고, 볼 수도 없다. (즉, 반드시 필요한 Section에 대해). 그리고 가장 처음으로 선언되는 Section은 default Section이 되며 역시 필수 Section이 된다.||
- NeoCoin/Server . . . . 1 match
Test
http://members.optusnet.com.au/ckolivas/kernel/ 리눅스커널 2.4.19 대의 여러 성능 향상 관련 패치 모음이에요. 벤치마크 보면 눈에 띠게 향상되네요. [http://contest.kolivas.net 요건 벤치마크 프로그램입니다] --동희
- NewTestsForOldBugs . . . . 1 match
Xper:NewTestsForOldBugs
- NotToolsButConcepts . . . . 1 match
- Test Driven Development
concentration, unit tests, and always trying to improve on yourself help
- ObjectOrientedReengineeringPatterns . . . . 1 match
[1002] 의 경우 Refactoring for understanding 이라는 녀석을 좋아한다. 그래서 가끔 해당 코드를 읽는중 생소한 코드들에 대해 일단 에디터에 복사한뒤, 이를 조금씩 리팩토링을 해본다. 중간중간 주석을 달거나, 이를 다시 refactoring 한다. 가끔 정확한 before-after 의 동작 유지를 무시하고 그냥 실행을 해보기도 한다. - Test 까진 안달아도, 적절하게 약간의 모듈을 추출해서 쓸 수 있었고, 코드를 이해하는데도 도움을 주었다. 이전의 모인모인 코드를 읽던중에 실천해봄.
- ObjectWorld . . . . 1 match
첫번째 Session 에는 ["ExtremeProgramming"] 을 위한 Java 툴들에 대한 간단한 언급이였습니다. 제가 30분 가량 늦어서 내용을 다 듣진 못했지만, 주 내용은 EJB 등 웹 기반 아키텍쳐 이용시 어떻게 테스트를 할것인가에 대해서와, Non-Functional Test 관련 툴들 (Profiler, Stress Tool) 에 대한 언급들이 있었습니다. (JMeter, Http Unit, Cactus 등 설명)
''Haven't read it. If I gave advice and I were to advise /you/, I'd advise more testing and programming, not more theory. Still, smoke 'em if ya got 'am.
- OperatingSystemClass/Exam2002_2 . . . . 1 match
public class TestProgram
- PersonalHistory . . . . 1 match
* 참고 페이지 - [GuiTesting]
- PragmaticVersionControlWithCVS/Getting Started . . . . 1 match
파일을 수정, UnitTest를 거치면 수정한 내용을 저장소에 저장해야할 것이다.
- PragmaticVersionControlWithCVS/HowTo . . . . 1 match
VersionControl 은 개발팀이 해야할 3가지 실천과제중의 한개. ( UnitTest, Automation )
- PrimeNumberPractice . . . . 1 match
public class PrimeNumberTest {
- Profiling . . . . 1 match
|| PerformanceTest || C/C++을 이용한 성능 측정 코드 작성 ||
- ProgrammingPearls/Column4 . . . . 1 match
* 가장 많이 쓰는 verification방법은 Test Case이다.
- ProjectAR/CollisionCheck . . . . 1 match
Upload:ARCollisionTest.zip
- ProjectPrometheus/Iteration3 . . . . 1 match
|| Iteration 2 AcceptanceTest 작성 || 1 || ○ ||
- ProjectWMB . . . . 1 match
* [TestDrivenDevelopment]
- ProjectZephyrus/Client . . . . 1 match
+ ---- TestSource - 라이브러리를 익히기 위해 만은 예제 프로그램들이 있는 디렉토리
- ProjectZephyrus/Server . . . . 1 match
+---- test : Test 관련 패키지
- PyIde/FeatureList . . . . 1 match
* UnitTest Runner
- PyServlet . . . . 1 match
class test(HttpServlet):
out.println("Testing...")
- QualityAttributes . . . . 1 match
* Testability
- RandomWalk/임인택 . . . . 1 match
TokenRing 에서 아이디어를 얻어 나름대로 만들어봤는데 (아직 제대로 동작하는지 미확인. 이 글을 작성하는 도중에도 버그가 하나둘 보이고 BadSmell 이 많이 난다. PC가 많은 곳에서 추가작업필요... :( ) 이게 CSP 의 이념에 부합하는지 모르겠다. m by n 배열에 있는 셀들을 TokenRingNetwork 형태를 띠게 하면서 사실은 배열인것처럼 동작하게 했다. 이 방법 말고 마땅한 방법이 떠오르지 않았다. TestDrivenDevelopment 으로 작성해보려고 했지만 실천에 옮기지 못했다. 몸에 밴 습관이란건 극복하기가 쉽지 않은 것 같다.
- Redmoon . . . . 1 match
DeletThisPage ? or DeleteTestAndWelcome ?
- Refactoring/MakingMethodCallsSimpler . . . . 1 match
== Replace Exception with Test ==
''Change the caller to make the test first''
- ReverseAndAdd/남상협 . . . . 1 match
import unittest
class testPalindrome(unittest.TestCase):
def testReverse(self):
def testRun(self):
unittest.main()
- Ruby/2011년스터디/세미나 . . . . 1 match
UnitTest::
- SilentASSERT . . . . 1 match
- Insert Test Title
- SmallTalk/문법정리 . . . . 1 match
TempTestCase>>initialize
- SmithNumbers/남상협 . . . . 1 match
int testCase;
cin>>testCase;
for(int i=0; i<testCase; i++)
/* Test Code
- SoftwareEngineeringClass/Exam2006_1 . . . . 1 match
3) S/W Test 와 Independent Verification & Validation 비교하라
- StaticInitializer . . . . 1 match
문제는 StaticInitializer 부분에 대해서 상속 클래스에서 치환을 시킬 수 없다는 점이다. 이는 꽤 심각한 문제를 발생하는데, 특히 Test 를 작성하는중 MockObject 등의 방법을 사용할 때 StaticInitializer 로 된 코드를 치환시킬 수 없기 때문이다. 저 안에 의존성을 가지는 다른 객체를 생성한다고 한다면 그 객체를 Mock 으로 치환하는 등의 일을 하곤 하는데 StaticInitialzer 는 아에 해당 클래스가 인스턴스화 될때 바로 실행이 되어버리기 때문에 치환할 수 없다.
- StepwiseRefinement . . . . 1 match
사실, TestDrivenDevelopment나 ["Refactoring"]의 상당 부분도 어찌보면 StepwiseRefinement의 연장선에 있다.
- TddRecursiveDescentParsing . . . . 1 match
RecursiveDescentParsing 을 TFP 로 시도를 해보려고 하는데.. Parser부분에 대한 test 의 결과를 얻기 위해서는 AST를 얻도록 해야 하고, AST를 조금씩 구축해나가는 방향으로 디자인유도중인데. 이 아이디어 생각하려는데 1시간을 소비했다. 흡;
["TestDrivenDevelopment"]
- Telephone . . . . 1 match
=== Test 배치 화일 작성하기 ===
그 다음 소스를 수정하실 때마다 test.bat 화일을 실행하시고, 비교해보세요.
'''test.bat'''
"""자신의프로그램이름""" < test1.in > out.txt
fc out.txt test1.out
'''test1.in'''
'''test1.out'''
- TestDrivenDevelopmentBetweenTeams . . . . 1 match
관련 문서 : http://groups.yahoo.com/group/testdrivendevelopment/files 에 Inter-team TDD.pdf
["TestDrivenDevelopment"]
- TheWarOfGenesis2R . . . . 1 match
* [http://zeropage.org/pub/Genesis2R//DXTest.rar 소스]
- TkinterProgramming/Calculator2 . . . . 1 match
[ ('Math', 'Test', 'B', KC1, FUN, 'math'),
- TugOfWar/남상협 . . . . 1 match
import unittest
class testTugOfWar(unittest.TestCase):
def testCoupling(self):
unittest.main()
- UnitTestFramework . . . . 1 match
UnitTest code 작성을 위한 Framework
* [gtest]
- VMWare . . . . 1 match
[VMWare/OSImplementationTest]
- VisualStudio . . . . 1 match
의외로 Debugger 를 이용하지 않는 사람들이 있다. UnitTest 를 작성하면서 프로그래밍을 하지 않는다면, Debugger는 불가피하다. 학교 프로그래밍 수업때 정식으로 가르치지 않기 때문에 MSDN이나 온라인의 강좌, 알고 있는 학우들에게 물어보아 배울수 있다.
- WikiSandPage . . . . 1 match
[임인택/ThisIsATestPage]
- XpWeek/20041220 . . . . 1 match
이건 혼자서 해 보세요. [http://www-903.ibm.com/developerworks/kr/java/library/j-xp042203.html Test-driven 프로그래밍] 강좌
- XpWeek/준비물 . . . . 1 match
|| TestDrivenDevelopmentByExample ||. ||. ||
- ZIM . . . . 1 match
* Test Case (by 테스트 팀)
- ZPBoard/PHPStudy/쿠키 . . . . 1 match
setcookie("CookieName", "Test Value");
- ZeroPageHistory . . . . 1 match
||1학기 ||회장 이창섭, 12기 회원 모집. ZeroWiki 시스템 도입. Devils 통합. Internet Problem Solving Contest 참여, 서강대 MentorOfArts 팀과 프로그래밍파티 개최 ||
* C++, Ajax, DirectX 2D, MFC, 3D, CAM, Unit Test, 영상처리
- ZeroPage성년식/거의모든ZP의역사 . . . . 1 match
||1학기 ||회장 이창섭, 12기 회원 모집. ZeroWiki 시스템 도입. Devils 통합. Internet Problem Solving Contest 참여, 서강대 MentorOfArts 팀과 프로그래밍파티 개최 ||
* C++, Ajax, DirectX 2D, MFC, 3D, CAM, Unit Test, 영상처리
- [Lovely]boy^_^/Diary/7/8_14 . . . . 1 match
* 석천이형이 봐오라고 한 TestDrivenDevelopment 랑 PyUnit 보고 있다.
- comein2 . . . . 1 match
* ExtremeProgramming 관련 UnitTest , Refactoring
- 강소현 . . . . 1 match
= [http://byule.com/board/ego Ego-Gram Test] =
- 그래픽스세미나/3주차 . . . . 1 match
|| 박경태 || Upload:OpenGLATL03_Pkt.zip ATL(??) 컴파일후 ATLTest.htm를 실행 ||
- 그래픽스세미나/5주차 . . . . 1 match
|| 윤정수 || Upload:Loader&Test.zip ||
- 김태진 . . . . 1 match
* SWTV(SW Testing&Verification) 연구실에 있습니다.
- 노스모크모인모인 . . . . 1 match
* ["상규/CPPUnitTestFramework/Source"]
- 데블스캠프2002/진행상황 . . . . 1 match
* ["RandomWalk2"] 를 ObjectOrientedProgramming 으로 구현하기 - 위의 Python 관련 실습동안 ["1002"] 는 ["RandomWalk2"] 에 대해서 C++ Prototype을 작성. (["RandomWalk2/ClassPrototype"]) 이를 뼈대로 삼아서 ["RandomWalk2"] 를 작성해보도록 실습. 해당 소스에 대한 간략한 설명, 구현의 예를 설명. 중간에 객체들에 대한 독립적인 테스트방법을 설명하면서 assert 문을 이용한 UnitTest 의 예를 보였다.
- 데블스캠프2005/주제 . . . . 1 match
[Refactoring], [TestDrivenDevelopment], [STL], [ObjectOrientedProgramming],
- 데블스캠프2009/금요일/SPECIALSeminar . . . . 1 match
* SI 업체의 경우 분석, 설계 후 Test가 다른 팀에 넘어가기도 하는 등 Feedback이 어렵다.
- 데블스캠프2009/수요일후기 . . . . 1 match
* '''서민관''' - 수요일 수업에서 제일 마음에 들었던 부분입니다. 이클립스를 써 본 것도 좋았고, 무엇보다 JUnit test는 정말 마음에 드네요. 앞으로 갈수록 프로그램의 크기가 커질텐데 이클립스를 통한 svn 사용이나 JUnit test나 둘 다 팀 프로젝트용으로는 정말 좋은 기능이라고 생각합니다. 정말 뭐라고 더 칭찬을 해야 할 지 말이 안 나올 정도로 마음에 들었어요. 한 방에 제대로 프로그램을 못 짜는 저한테는 메인 함수 없이도 버그 수정이 가능하다는 건 정말 고마운 기능이죠.
* '''박준호''' - 처음으로 JAVA 에 대해 제대로 코딩도 해보고 접해본 시간 이였습니다. JUnit test 라는 것을 이용하여 팀플에서 얼마나 유용하게 쓰일지는.. 정말 무궁무진 할꺼 같습니다. 저도 빠른 시일내에 까먹지 않고 쓸 수 있게 되었으면 좋겠습니다.
* [송지원] - 사실 너무 아쉬웠다. JUnitTest를 위해 예로 제시한 계산기 클래스도 함수 하나 정도밖에 테스트 해볼 수 없는 이상한 설계의 클래스였다(너무 OOP 다음수업이라 캡슐화에만 신경을 썼던듯). 한 마디로 Java도, JUnit도 맛보기만 해준 꼴이 된것 같다. 하지만 '''JUnit은 확실히 강한 라이브러리다'''. 내가 몸소 느끼고 자발적으로 세미나한 이유도 그렇다. 내 세미나는 즈질이였지만 많은 1,2학년 학우들이 Java로 개발을 진행할 때 도움이 되었으면 한다.
- 데블스캠프2011/넷째날/Git/권순의 . . . . 1 match
#include "cmdTest.h"
return testCmd;
- 데블스캠프2011/둘째날/Machine-Learning/NaiveBayesClassifier/송지원 . . . . 1 match
* 다른 분들과 달리, 저는 한 글자인 문자와 특수문자를 첫 글자로 포함하는 단어들은 Train Data 및 Test Data 분석에 포함시키지 않았습니다.
=== test File Analysis ===
public class testFileCal {
testFileCal(String f){
public void testArticleRead(List<String> data, List<Integer> frequency, List<String> data2, List<Integer> frequency2){
//testFileCal testE = new testFileCal("D:/economy.txt");
testFileCal testP = new testFileCal("D:/politics.txt");
//testE.testArticleRead(ec.data, ec.frequency, po.data, po.frequency);
testP.testArticleRead(po.data, po.frequency, ec.data, ec.frequency);
testP.printBayes();
- 데블스캠프2011/둘째날/Machine-Learning/SVM/namsangboy . . . . 1 match
maketestdir = lambda i : "/home/newmoni/workspace/svm/package/test/"+i+"/"+i+".txt"
doclist = open(maketestdir(eachclass)).read().split("\n")
* SVM Test 파일 생성
svmttest = "../data/test2.svm_light"
fout = file(svmttest,"a")
doclist = open(maketestdir(eachclass)).read().split("\n")
- 데블스캠프2011/첫째날/Java . . . . 1 match
* JUnitTest (with JUnit 4 plug-in)
- 데블스캠프2011/첫째날/개발자는무엇으로사는가 . . . . 1 match
* 이럴 때 Unit Test를 이용하는 겁니다. - [지원]
- 데블스캠프2012/넷째날/묻지마Csharp/Mission3/김준석 . . . . 1 match
namespace TestWindowFormDevils
- 디자인패턴 . . . . 1 match
* http://www.econ.kuleuven.ac.be/tew/academic/infosys/Members/Snoeck/litmus2.ps - Design Patterns As Litmus Paper To Test The Strength Of Object Oriented Methods
- 레밍즈프로젝트/프로토타입/MFC더블버퍼링 . . . . 1 match
Test는 OnDraw 상에서 하였다. OnDraw는 Invalidate를 통해서 OnPaint가 호출되면 자동으로 호출된다.
- 레밍즈프로젝트/프로토타입/STLLIST . . . . 1 match
|| IsEmpty || Tests for the empty list condition (no elements). ||
- 몸짱프로젝트/BucketSort . . . . 1 match
* 개발방식 : TestDrivenDevelopment using [JUnit]
- 몸짱프로젝트/KnightTour . . . . 1 match
* TestDrivenDevelopment 방식을 씀
- 무엇을공부할것인가 . . . . 1 match
- Test Driven Development
concentration, unit tests, and always trying to improve on yourself help
- 반복문자열/이태양 . . . . 1 match
class TestClass{
- 상협/감상 . . . . 1 match
|| [TestDrivenDevelopmentByExample] || 켄트벡 || 1 || 굿 || 아직 제대로 이해와 적용은 못하겠다. 그래도 좋은책~ ||
- 새싹교실/2011/쉬운것같지만쉬운반/2011.5.3 . . . . 1 match
* 학습 ( SelfTest )
- 새싹교실/2012/주먹밥 . . . . 1 match
* 절대 경로와 상대경로. '절대 경로'는 운영체제 기준으로 운영체제가 젤 세부로 나눠주는 드라이브를 비유해서 설명해주었습니다. 운영체제 기준으로 {{{ C:\\Desktop\test.txt }}}를 같은 폴더 프로그램으로 불러와봅시다. 잘불러와지네요? 하지만 {{{C:\\Desktop\오리\test.txt }}}로 저 txt파일과 프로그램을 옮기면 실행이 될까요? 안되죠? 같은 폴더에 있는데도. 그럼 어떻게 해야할까요? 그래서 상대경로 라는것이 나왔습니다. {{{ .\test.txt }}} 면 같은 폴더에 있는 test파일을 찾고. {{{ ..\test.txt}}} 는 바로 위 상위폴더를 찾습니다. 다른폴더는 어떻게 하나고요? {{{ .\오리\test.txt }}}로 설정하면되죠. '''상대 경로'''는 해당 실행파일 기준으로 파일 위치를 추적 하는것이랍니다.
* 리다이렉션 > 표시는 현재 출력을 다른곳으로 돌릴때 쓴다고 했죠. 현재 이 test.exe파일을 실행시키면 5를 출력한다고 합니다
윈도우의 CMD에서 이파일을 리다이렉션을 통해 test.txt로 출력을 시켜보겠습니다
test.exe > test.txt
를 하면 test.txt 에는 5가 들어가게됩니다.
public class MyTest {
- 서민관 . . . . 1 match
"Test String"
- 송지원 . . . . 1 match
수요일 Simple Java & JUnit Test([데블스캠프2009/수요일/JUnit])를 주제로 세미나 진행.
- 수학의정석 . . . . 1 match
See Also PerformanceTest
- 수행시간측정 . . . . 1 match
#redirect PerformanceTest
- 영어학습방법론 . . . . 1 match
WPM을 체크하는 Test자료들은 웹에 많이 있음. WPM test용 원문은 많은 제약사항(모르는 단어, 어려운 단어수 등)이 있는 text임
- 영호의해킹공부페이지 . . . . 1 match
Here is a 10 step description for enabling the net monitor (field test
Choose menu 6 (Field Test Display Settings).
Go to the menu net monitor and at the test prompt enter 241 to deactivate the
the small net monitor by entering 242 at the test prompt (if menu net monitor
- 오목/곽세환,조재화 . . . . 1 match
virtual BOOL PreCreateWindow(CREATESTRUCT& cs);
BOOL COhbokView::PreCreateWindow(CREATESTRUCT& cs)
// the CREATESTRUCT cs
//MessageBox("Test");
- 작은자바이야기 . . . . 1 match
* test-resourecs - src/test/resources의 설정파일 등을 target/test-classes로 전달.
* mvn test - 컴파일을 하고 나서 src/test/java를 컴파일해서 target/test-classes로. @Test 실행 <scope>가 언제 사용되는지 결정
.setUrl("jdbc:mysql://zeropage.org:3306/test")
.setUser("test")
.setPassword("test")
- 전문가되기세미나 . . . . 1 match
* Technical Environment with Automated Tests, Configuration Management, and Frequent Integration
- 정모/2011.4.4 . . . . 1 match
1. 다음번엔 TDD로 CodeRace를 진행해보자는 의견이 있었습니다. 정말 좋은 의견인데 대책없이 적용시킬수는 없겠다는 생각이 드네요. 하지만 굉장히 매력적인 의견이었습니다. 여름방학이나 2학기때 Test-driven CodeRace를 꼭 해보고 싶네요.
- 중위수구하기/문보창 . . . . 1 match
==== {{{~cpp TestNumber.java}}} ====
public class testNumber
- 지금그때2003/ToDo . . . . 1 match
* 일정 계획 Test (X)
- 프로젝트 . . . . 1 match
* 참고 페이지 - [GuiTesting]
Found 340 matching pages out of 7540 total pages (5000 pages are searched)
You can also click here to search title.
