- Armdroid/3회차
class fooTest extends TestCase{
- CppUnit
= 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
CPPUNIT_TEST_SUITE( ExampleTestCase ); // TestSuite
CPPUNIT_TEST( testExample ); // TestCase 의 등록.
== ExampleTestCase.cpp ==
#include "ExampleTestCase.h"
CPPUNIT_TEST_SUITE_REGISTRATION( ExampleTestCase ); // TestSuite 를 등록하기. TestRunner::addTest 가 필요없다.
void ExampleTestCase::testExample () // 테스트 하려는 함수.
void ExampleTestCase::setUp () // fixture 관련 셋팅 코드.
void ExampleTestCase::tearDown () // fixture 관련 셋팅 코드.
#include <cppunit/TestCase.h>
class SimpleTestCase : public CppUnit::TestCase {
CPPUNIT_TEST_SUITE ( SimpleTestCase );
CPPUNIT_TEST_SUITE_REGISTRATION (SimpleTestCase);
=== 준비 - 2 TestCase 만들기를 위한 세팅 ===
- EightQueenProblemDiscussion
즉, 실제 Queen의 위치들을 정의하는 재귀호출 코드인데요. 이 부분에 대한 TestCase 는 최종적으로 얻어낸 판에 대해 올바른 Queen의 배열인지 확인하는 부분이 되어야 겠죠. 연습장에 계속 의사코드를 적어놓긴 했었는데, 적어놓고 맞을것이다라는 확신을 계속 못했죠. 확신을 위해서는 테스트코드로 뽑아낼 수 있어야 할텐데, 그때당시 이 부분에 대해서 테스트코드를 못만들었죠.
- JTDStudy/첫번째과제/상욱
import junit.framework.TestCase;
public class NumberBaseBallGameTest extends TestCase {
* 테스트 코드를 갖고 어떻게 해야하는지 잘 모르겠어요. import junit.framework.TestCase 구문이 있던데 이것은 어디서 가져와야 하나요? -_-;; - [문원명]
import junit.framework.TestCase;
public class JUnit38Test extends TestCase {
- JUnit/Ecliipse
다음으로 자신이 테스트를 하고 싶은 메서드에 체크를 하고 Finish 하면 TestCase를 상속받는 새 클래스를 자동으로 생성하여 줍니다.
public class Ch03_01Test extends TestCase {
* @see TestCase#setUp()
* @see TestCase#tearDown()
public class Ch03_01Test extends TestCase {
* @see TestCase#setUp()
* @see TestCase#tearDown()
- NUnit
* 어떠한 클래스라도 즉시 Test를 붙일수 있다. (반면 JUnit 은 TestCase 를 상속받아야 하기 때문에, 기존 product소스가 이미 상속 상태라면 Test Fixture가 될수 없다. )
* Java 1.5 에 메타 테그가 추가되면 NUnit 방식의 TestCase 버전이 나올것 같다. 일단 이름의 자유로움과, 어떠한 클래스라도 Test가 될수 있다는 점이 좋왔다. 하지만, TestFixture 를 붙여주지 않고도, 목표한 클래스의 Test 들을 실행할 수 있는 방식이면 어떨까 생각해 본다. --NeoCoin
- ProjectPrometheus/Journey
* TestCase 통과 위주 ZeroPageServer 에서 TestCase 돌려봄
* TestCase 만들어 둔것을 상속 받아서, 다시 다른 테스트를 수행 시키는 기법이 정말 흥미로웠다. 진짜 신기하다. 생각하면 할수록 신기하다.
* test {{{~cpp TestCase}}}
* 모든 {{{~cpp TestCase TestSuite}}} 는 독립적으로 실행할수 있다.
- PyIde/Exploration
unittest 모듈을 프린트하여 Code 분석을 했다. 이전에 cgi 로 test runner 돌아가게끔 만들때 구경을 해서 그런지 별로 어렵지 않았다. (조금 리팩토링이 필요해보기는 코드같긴 하지만.. JUnit 의 경우 Assert 가 따로 클래스로 빠져있는데 PyUnit 의 경우 TestCase 에 전부 implementation 되어서 덩치가 약간 더 크다. 뭐, 별 문제될 부분은 아니긴 하다.
- PyUnit
=== TestCase ===
PyUnit에서는 TestCase는 unittest모듈의 TestCase 클래스로서 표현된다.testcase 클래스를 만들려면 unittest.TestCase를 상속받아서 만들면 된다.
=== 간단한 testcase 의 제작. 'failure', 'error' ===
class DefaultWidgetSizeTestCase(unittest.TestCase):
테스팅을 하기 위해 Python의 assert 구문을 사용한다. testcase가 실행될 때 assertion을 실행하면 AssertionError 가 일어나고, testing framework는 이 testcase를 'failure' 했다고 정의할 것이다. 'assert' 를 명시적으로 써놓지 않은 부분에서의 예외가 발생한 것들은 testing framework 에서는 'errors'로 간주한다.
testcase를 실행하는 방법은 후에 설명할 것이다. testcase 클래스를 생성하기 위해 우리는 생성자에 아무 인자 없이 호출해주면 된다.
testCase = DefaultWidgetSizeTestCase ()
만일 testcase가 많아지면 그들의 set-up 코드들도 중복될 것이다. 매번 Widget 클래스를 테스트하기 위해 클래스들마다 widget 인스턴스를 만드는 것은 명백한 중복이다.
class SimpleWidgetTestCase(unittest.TestCase):
class DefaultWidgetSizeTestCase(SimpleWidgetTestCase):
class WidgetResizeTestCase(SimpleWidgetTestCase):
class SimpleWidgetTestCase (unittest.TestCase):
=== 여러개의 test method를 포함한 TestCase classes ===
종종, 많은 작은 test case들이 같은 fixture를 사용하게 될 것이다. 이러한 경우, 우리는 DefaultWidgetSizeTestCase 같은 많은 작은 one-method class 안에 SimpleWidgetTestCase를 서브클래싱하게 된다. 이건 시간낭비이고,.. --a PyUnit는 더 단순한 메커니즘을 제공한다.
class WidgetTestCase (unittest.TestCase):
defaultSizeTestCase = WidgetTestCase ("testDefaultSize")
resizeTestCase = WidgetTestCase ("testResize")
=== TestSuite : testcase들의 집합체 ===
widgetTestSuite.addTest (WidgetTestCase ("testDefaultSize"))
widgetTestSuite.addTest (WidgetTestCase ("testResize"))
- TFP예제/Queue
''TestCaseQueue.py''
suite = unittest.makeSuite (QueueTestCase, "test")
''TestCaseQueue.py''
class QueueTestCase (unittest.TestCase):
suite = unittest.makeSuite (QueueTestCase, "test")
ERROR: testCount (TestCaseQueue.QueueTestCase)
File "C:\USER\reset\TestCaseQueue.py", line 5, in testCount
ERROR: testCount (TestCaseQueue.QueueTestCase)
File "C:\USER\reset\TestCaseQueue.py", line 7, in testCount
FAIL: testCount (TestCaseQueue.QueueTestCase)
File "C:\USER\reset\TestCaseQueue.py", line 8, in testCount
class QueueTestCase (unittest.TestCase):
suite = unittest.makeSuite (QueueTestCase, "test")
FAIL: testCount (TestCaseQueue.QueueTestCase)
File "C:\USER\reset\TestCaseQueue.py", line 10, in testCount
suite = unittest.makeSuite (QueueTestCase, "test")
FAIL: testCount (TestCaseQueue.QueueTestCase)
File "C:\USER\reset\TestCaseQueue.py", line 8, in testCount
class QueueTestCase (unittest.TestCase):
suite = unittest.makeSuite (QueueTestCase, "test")
- TestCase
TestCase란 만들고자 하는 대상이 잘 만들어졌다면 무사히 통과할 일련의 작업을 말한다. TestCase는 작성하고자하는 모듈의 내부 구현과 무관하게
XP에서 TestCase를 먼저 작성함으로서 프로그래머가 내부 구현에 신경쓰다가 정작 그 원하는 동작(예를 들어, 다른 모듈과의 인터페이스)을 놓칠 위험을 줄여준다. 왜냐하면, 프로그래머는 먼저 만든 TestCase를 통과하는 것을 첫번 목표로 삼을 수 있기 때문이다.
-> Xp 에서 프로그래머는 TestCase 를 통과하는 것을 목표를 삼는다. 그래서 구현이나 디자인에 신경쓰다 원하는 모듈을 오동작으로 이끄는 위험을 줄인다.
- TestFirstProgramming
어떻게 보면 질답법과도 같다. 프로그래머는 일단 자신이 만들려고 하는 부분에 대해 질문을 내리고, TestCase를 먼저 만들어 냄으로서 의도를 표현한다. 이렇게 UnitTest Code를 먼저 만듬으로서 UnitTest FrameWork와 컴파일러에게 내가 본래 만들고자 하는 기능과 현재 만들어지고 있는 코드가 하는일이 일치하는지에 대해 어느정도 디버깅될 정보를 등록해놓는다. 이로서 컴파일러는 언어의 문법에러 검증뿐만 아니라 알고리즘 자체에 대한 디버깅기능을 어느정도 수행해주게 된다.
Found 12 matching pages out of 7540 total pages
You can also click here to search title.
