- TestFirstProgramming . . . . 7 matches
어떻게 보면 질답법과도 같다. 프로그래머는 일단 자신이 만들려고 하는 부분에 대해 질문을 내리고, TestCase를 먼저 만들어 냄으로서 의도를 표현한다. 이렇게 UnitTest Code를 먼저 만듬으로서 UnitTest FrameWork와 컴파일러에게 내가 본래 만들고자 하는 기능과 현재 만들어지고 있는 코드가 하는일이 일치하는지에 대해 어느정도 디버깅될 정보를 등록해놓는다. 이로서 컴파일러는 언어의 문법에러 검증뿐만 아니라 알고리즘 자체에 대한 디버깅기능을 어느정도 수행해주게 된다.
ExtremeProgramming에서는 UnitTest -> Coding -> ["Refactoring"] 이 맞물려 돌아간다. TestFirstProgramming 과 ["Refactoring"] 으로 단순한 디자인이 유도되어진다.
* wiki:Wiki:CodeUnitTestFirst, wiki:Wiki:TestFirstDesign, wiki:Wiki:TestDrivenProgramming
* wiki:Wiki:ExtremeProgrammingUnitTestingApproach
테스트 코드 작성에 대해서는 UnitTest 와 PyUnit, CppUnit 를 참조하라.
이 경우에도 ["MockObjects"] 를 이용할 수 있다. 기본적으로 XP에서의 테스트는 자동화된 테스트, 즉 테스트가 코드화 된 것이다. 처음 바로 접근이 힘들다면 Mock Server / Mock Client 를 만들어서 테스트 할 수 있겠다. 즉, 해당 상황에 대해 이미 내장되어 있는 값을 리턴해주는 서버나 클라이언트를 만드는 것이다. (이는 TestFirstProgramming 에서보단 ["AcceptanceTest"] 에 넣는게 더 맞을 듯 하긴 하다. XP 에서는 UnitTest 와 AcceptanceTest 둘 다 이용한다.)
- REFACTORING . . . . 4 matches
* 기존의 "디자인 후 코딩' 법칙과 반대된다. (TestFirstProgramming 에서 UnitTest - ["Refactoring"] 이 맞물려 돌아간다)
* Refactoring 을 하기 위해서는 UnitTest code가 필수적이다. 일단 처음 Refactoring에 대한 간단한 원리를 이해하고 싶다면 UnitTest 코드 없이 해도 좋지만, UnitTest code를 작성함으로서 Refactoring 에 대한 효과를 높일 수 있다. (Refactoring 중 본래의 외부기능을 건드리는 실수를 막을 수 있다.)
- VendingMachine/재니 . . . . 3 matches
''클래스 수가 많아서 복잡해진건 아닌듯(모 VendingMachine 의 경우 Requirement 변경에 따라 클래스갯수가 10개 이상이 되기도 함; 클래스 수가 중요하다기보다도 최종 완료된 소스가 얼마나 명료해졌느냐가 복잡도를 결정하리라 생각). 단, 역할 분담할때 각 클래스별 역할이 명료한지 신경을 쓰는것이 좋겠다. CoinCounter 의 경우 VendingMachine 안에 멤버로 있어도 좋을듯. CRC 세션을 할때 클래스들이 각각 따로 존재하는 것 같지만, 실제론 그 클래스들이 서로를 포함하고 있기도 하거든. 또는 해당 기능을 구현하기 위해 다른 클래스들과 협동하기도 하고 (Collaboration. 실제 구현시엔 다른 클래스의 메소드들을 호출해서 구현한다던지 식임). 역할분담을 하고 난 다음 모의 시나리오를 만든뒤 코딩해나갔다면 어떠했을까 하는 생각도 해본다. 이 경우에는 UnitTest 를 작성하는게 좋겠지. UnitTest 작성 & 진행에 대해선 ["ScheduledWalk/석천"] 의 중반부분이랑 UnitTest 참조.--["1002"]''
- 데블스캠프2009/수요일 . . . . 3 matches
|| 송지원 || Simple Java & JUnitTest || Java의 간단한 문법과 개념을 배우고,[[br]]JUnitTest를 통해 TDD 기반의 프로그래밍에 대해 맛보기. || 아무래도 Test가[[br]]메인이다 보니,[[br]]Java를 통한 OOP 개념의 실습은[[br]]시간상 진행하지 않는다. ||
||am 04:00~05:00 || TDD의 개념과 JUnitTest 실습 || 송지원 ||
- GuiTesting . . . . 2 matches
See Also wiki:Wiki:GuiTesting, wiki:Wiki:GuiUnitTesting, [http://www.xp123.com/xplor/xp0001/ JavaGuiTesting] , ["GuiTestingWithMfc"], ["GuiTestingWithWxPython"]
["UnitTest"]
- JUnit . . . . 2 matches
Java 언어를 위한 UnitTest Framework.
JUnit 에서 UnitTest (PyUnit) 에서처럼 testing message 나오게 하려면 어떻게 해야 하죠..? -임인택
- ProjectPrometheus/CookBook . . . . 2 matches
=== ZeroPageServer 에서 UnitTest ===
ZeroPageServer 에 릴리즈 한뒤 UnitTest 하기.
- AcceptanceTest . . . . 1 match
요새는 CustomerTest 라고 표현하기도 한다. (UnitTest 를 ProgrammerTest 라고 부른다고 할때 상대적인 개념일듯).
- CxxTest . . . . 1 match
C++ 의 경우는 언어차원에서의 리플랙션을 지원하지 않기 때문에 테스트를 추가하는 부분이 자바나 파이썬 등에 비해 상당히 귀찮다. 그에 대한 대안으로 [CUT] 등의 C UnitTestFramework 의 경우 외부에서 Perl 등으로 작성한 스크립트언어로 테스트실행과 관련한 Runner 를 코드제너레이팅하는 방법을 쓰고 있다.
- MineFinder . . . . 1 match
* 지뢰찾기 프로그램의 윈도우 핸들을 얻고 해당 메세지를 보내어서 지뢰찾기 프로그램을 구동하는 루틴 관련 SpikeSolution. (아.. UnitTest 코드 넣기가 애매해서 안넣었다. 궁리해봐야 할 부분같다.)
- PairProgramming . . . . 1 match
* 하지만 UnitTest도 그렇듯이, 많은 장점을 가진 방법을 완벽하지 않다는 이유로 사용하지 않는다는 것은 아쉬운 일일 것이다.
- PragmaticVersionControlWithCVS/HowTo . . . . 1 match
VersionControl 은 개발팀이 해야할 3가지 실천과제중의 한개. ( UnitTest, Automation )
- PythonLanguage . . . . 1 match
* TestFirstProgramming, UnitTest(PyUnit 참고), ["Refactoring"] 등의 방법론을 같이 접목시키면 더욱 큰 효과를 발휘할 수 있다.
- Ruby/2011년스터디/세미나 . . . . 1 match
UnitTest::
- SeminarHowToProgramItAfterwords . . . . 1 match
* ["neocoin"] : UnitTest에서 추구한 프로그램의 설계에서 Divide해 나가는 과정은 여태 거의 디자인 타임에서 거의 수행을 했습니다. 그래서 여태 Test를 위한 코드들과 디버그용 코드들을 프로그램을 작성할때마다 그런 디자인에도 많은 시간을 소요했는데, 아예 프로그램의 출발을 Test에서 시작한다는 발상의 전환이 인상 깊었습니다. --상민
- UnitTestFramework . . . . 1 match
UnitTest code 작성을 위한 Framework
- 데블스캠프2002/진행상황 . . . . 1 match
* ["RandomWalk2"] 를 ObjectOrientedProgramming 으로 구현하기 - 위의 Python 관련 실습동안 ["1002"] 는 ["RandomWalk2"] 에 대해서 C++ Prototype을 작성. (["RandomWalk2/ClassPrototype"]) 이를 뼈대로 삼아서 ["RandomWalk2"] 를 작성해보도록 실습. 해당 소스에 대한 간략한 설명, 구현의 예를 설명. 중간에 객체들에 대한 독립적인 테스트방법을 설명하면서 assert 문을 이용한 UnitTest 의 예를 보였다.
- 데블스캠프2009/수요일후기 . . . . 1 match
* [송지원] - 사실 너무 아쉬웠다. JUnitTest를 위해 예로 제시한 계산기 클래스도 함수 하나 정도밖에 테스트 해볼 수 없는 이상한 설계의 클래스였다(너무 OOP 다음수업이라 캡슐화에만 신경을 썼던듯). 한 마디로 Java도, JUnit도 맛보기만 해준 꼴이 된것 같다. 하지만 '''JUnit은 확실히 강한 라이브러리다'''. 내가 몸소 느끼고 자발적으로 세미나한 이유도 그렇다. 내 세미나는 즈질이였지만 많은 1,2학년 학우들이 Java로 개발을 진행할 때 도움이 되었으면 한다.
Found 18 matching pages out of 7557 total pages (2100 pages are searched)
You can also click here to search title.
