반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리

jUnit 으로 Private Method 테스트 만들기

2013. 6. 10. 08:05 | Posted by 솔웅


반응형

TDD 프로젝트에 join 한지 두달이 넘어갑니다.
이제 Spring Framwork 에서 JUnit 테스트 만드는 일은 제법 익숙해 졌어요.

오늘은 Private 메소드에 대한 JUnit 테스트 만드는 방법을 정리해 두어야 겠습니다.

우선 Method 메소드를 만들어서 테스트할 private 메소드를 담을 겁니다.


Method m = singlePaymentController.getClass().getDeclaredMethod("method name",input parameter -class-);

singlePaymentController 는 테스트할 클래스 이름인데요.


미리 인스턴스를 생성해 놓은 변수 입니다. (SinglePaymentController singlePaymentController = new SinglePaymentController(); 이렇게요.

 

그 클래스에서 getClass()를 안의 getDeclaredMethod() 를 불러 냅니다.
private 메소드를 외부에서 접근할 때는 이 getDeclaredMethod()를 사용하고 private field 에 접근할 때는 getDeclaredField() 나 getDeclaredFields를 사용합니다.


이 밖에서getDeclaredConstructor(), getDeclaredClass() 등 여러가지가 있습니다. 필요할 때 사용하면 됩니다.

 

getDeclaredMethod() 안에 들어가는 인자들은 해당 메소드 이름이 string으로 들어가고 그 다음엔 그 메소드의 input parameter 들을 열거하면 됩니다.

 

그러면 테스트 하고 싶은 private 메소드를 Method 객체 안에 담을 수가 있습니다.

m.setAccessible(true);

 

이제 위 코드 처럼 해당 private 메소드를 접근할 수 있도록 합니다.
이제 외부에서 그 private 메소드에 접근 할 수 있습니다.

 

이제 해당 private method 를 실행시키면 됩니다.


invoke 메소드를 사용하는데요.


그 private method를 담은 Method 객체를 invoke 해 주면 됩니다.
m.invoke() 이렇게요.

 

여기서 invoke 안에는 그 private 메소드가 들어있는 class와 private method 에 전달 될 input parameter 를 넣어 주면 됩니다.

 

private 메소드가 들어있는 클래스는 아까 사용했던 singlePaymentController 가 되겠네요.
그리고 그 private method의 input parameter는 새로 생성해서 테스트 데이터를 넣어 주셔야 됩니다.

 

input parameter 에 필요한 값들 넣기

m.invoke(클래스 이름, input parameter)

 

assert 하기

이렇게해서 해당 private method 안에서 처리되어야 할 값들을 assert 문에 넣어서 예상값과 실제 처리된 값을 비교하면 되겠죠.

 

만약 그 private 메소드가 return 값이 있다면 invoke 해서 return 되는 값을 받아서 그 값을 가지고 assert 하면 됩니다.

 

지금 작업하고 있는 소스를 올릴 수가 없어서 간단하게 따로 만들어 봤습니다.

직접 소스를 보면서 한번 더 익혀 보죠.

 

public class privatemethod

{

private String jUnitPrivate(String a, String b) {

String result = null;

result = a + " : " +b;

return result;

}

}

 

 

아주 간단한 소스 입니다.

그런데 메소드가 private 이죠?

이 메소드에 대한 jUnit test를 만들겠습니다.

 

우선 이 테스트할 클래스에 대한 인스턴스를 생성합니다.

privatemethod jPrivate = new privatemethod();

 

그 다음에는 해당 private 메소드를 담을 Method 객체 생성합니다.

Method m;

 

그리고 이 객체에 해당 private method 를 담습니다.

m = jPrivate.getClass().getDeclaredMethod("jUnitPrivate",String.class,String.class);

 

이제 이 메소드에 대한 접근을 허용해 줍니다.

m.setAccessible(true);

 

그리고 나서 invoke 메소드를 사용해서 이 메소드를 호출합니다.

호출 할 때는 input parameter들을 만들어서 같이 보내 줘야 겠죠?

 

String result =null;

String a = "Korea";

String b = "Seoul";

result = (String) m.invoke(jPrivate,a,b);

 

이제 result 객체에 return 값이 담겼을 테니까 그 결과에 대한 예상값과 실제 값을 가지고 assert 을 해야겠죠.

 

assertEquals("Korea : Seoul",result);

 

이렇게 하고 jUnit 을 돌리면 아래와 같이 녹색을 볼 수 있습니다.

 

 

 

 
완성된 소스는 아래와 같습니다.
 
 
 

public class jUnitPrivateTest

 

{

@Test

public void testJUnitPrivate(){

privatemethod jPrivate = new privatemethod();

Method m;

try

{

m = jPrivate.getClass().getDeclaredMethod("jUnitPrivate",String.class,String.class);

m.setAccessible(true);

String result =null;

String a = "Korea";

String b = "Seoul";

result = (String) m.invoke(jPrivate,a,b);

assertEquals("Korea : Seoul",result);

}

catch (Exception e)

{

// TODO Auto-generated catch block

e.printStackTrace();

}

}

/**

* @throws java.lang.Exception

*/

@BeforeClass

public static void setUpBeforeClass() throws Exception

{

}

/**

* @throws java.lang.Exception

*/

@AfterClass

public static void tearDownAfterClass() throws Exception

{

}

/**

* @throws java.lang.Exception

*/

@Before

public void setUp() throws Exception

{

}

/**

* @throws java.lang.Exception

*/

@After

public void tearDown() throws Exception

{

}

}

 
아래 소스를 다운받으셔서 테스트 해 보셔도 되요.
 
 
privatemethod.java
 
jUnitPrivateTest.java
 
반응형


반응형

TDD 관련 아티클을 정리하고 있는데 오늘로서 완료할 것 같네요.

이 글을 읽고 TDD 에 대해서 많이 개념이 잡힌것 같습니다.

 

TDD from starting from user stories - a top-down style 03

 

 

A sample

 

실제 샘플 코드를 한번 보죠. 웹 어플리케이션 관련 작업을 하고 있다고 가정해 봅시다. 여기 로그인 기능과 관련한 스토리가 있습니다.

 

유저가 웹 사이트에 로그인하려고 합니다. 이 때 그 유저는 등록된 유저를 위한 어떤 기능을 사용할 수 있게 됩니다.

 

이 스토리에 대한 acceptance criteria 를 보면

 

* Happy path: 성공적인 로그인
Given: 유저가 로그인 페이지로 감
When: 제대로 된 아이디와 패스워드를 입력하고 submit 함
Then: 유저는 성공했다는 메세지와 함께 로그인 하게 됨

 

* Username or password missing
Given: 유저가 로그인 페이지로 감
When: 아이디나 비밀번호를 입력하지 않고 submit 버튼을 누름
Then: 유저는 "username or password missing" 이라는 에러 메세지를 보게 됨

 

* Username or password incorrect
Given: 유저가 로그인 페이지로 감
When: 맞지 않는 아이디나 비밀번호를 입력하고 submit 버튼을 누름
Then:  유저는 “username or password is not correct” 라는 에러 메세지를 보게 됨

 

 


웹 어플리케이션을 만들기 위해 Ruby on Rail 을 사용한다고 가정해 봅시다. 우리는 이 스토리에 대해 쉽게 acceptance test를 사용할 수 있습니다.

 

<src lang="ruby">
Story "Login", %(
        As a user,
        I want to sign in the website,
        So that I can use registered user specific functionality) do

        @selenium = Selenium::SeleniumDriver.new("localhost", 4444, "*iexplore", "http://localhost", 10000);

      Scenario "user successfully login" do
        Given "correct username and password" do
            @selenium.start
            @selenium.open "http://localhost/users/login"
            @selenium.type "username", "someone"
            @selenium.type "password", "password"
        end

        When "login" do
            @selenium.click "submit"
        end

        Then "user logged in successfully" do
            @selenium.is_text_present "Welcome, someone!"
            @selenium.stop
        end

    end

    other scenarios...

end
</src>


rbehave는 ruby code를 사용해서 business acceptance criteria 를 표현하기 위해 사용하는 프레임워크가 rbehave 입니다. 이 테스트를 작성하고 난 후 run 하고 실패하는 것을 확인하게 됩니다. 이제 이 test를 pass 하도록 하기 위해 어떻게 해야 하는지를 생각 할 수 있습니다. 이 시점에서 로그인 하기 위한 UserController 와 action 그리고 User Model을 call 하는 것을 만들어야 할 것입니다. 일단 무엇인가 만들기로 결심하면 코딩을 시작하게 되겠죠.

 


<src lang="ruby">
def test_registered_user_should_able_to_sign_in_and_redirect_to_home_as_default
    post :login, :name => "someone", :password => "password"
    assert_equal "Welcome, someone!", flash[:notice]
end
</src>

 

여기서 테스트 하는 Users control의 로그인 action은 login을 perform 해야하고 flash notice를 set 해야 합니다. 그리고 나서 우리는 controller action쪽으로 갈 겁니다.

 

<src lang="ruby">
def signin
    user = User.authenticate(params[:name], params[:password])
    flash[:notice] = "Welcome, " + user.nickname + "!"
    redirect_to :controller => "home"
end
</src>

우리는 User model에게 authentication을 위임 합니다. 여기에 대한 테스트를 작성할 수 있겠죠.

<src lang="ruby">
def should_be_able_to_get_authenticated_user
    assert_equal users(:someone), User.authenticate("some user", "user's password")
    ...
end
</src>

 

이렇게 하면 쉽게 간단한 코드를 작성해서 이 authenticate method를 구현할 수 있습니다. 여기서 너무 exception handling에 대해 염려하실 필요는 없습니다. 좀 더 많은 테스트 케이스들을 만든 다음에 점차 우리의 코드를 점점 알차게 다듬을 겁니다.

 

지금까지 간단한 스토리에 대한 그럴듯한 시나리오를 implement 하는 과정을 보여드렸습니다. 조각조각 여러 부분으로 나눈 다음에 문제를 푸는 과정을 기억해 두세요. 한번에 한 조각식 일을 진행합니다. 우선 test를 먼저 작성하고 그것을 pass 하기 위해 가장 간단한 코딩을 찾습니다. 이렇게 함으로서 각 스텝마다 아주 confident 하게 일을 진행할 수 있게 됩니다. 그리고 지금 우리가 만들고 있는 것의 가치를 분명하게 볼 수 있구요.

 

 

Variations

 

Lack of tools support

 

가끔 테스팅 툴이 없어서 해당 어플리케이션에 대한 모든 시나리오에 대한 functional test를 작성할 수 없을 때가 있습니다. 이런 경우엔 좀 더 생각을 확장해서 이러한 문제를 해결해야 합니다. 예를 들어 전체 어플리케이션이 아니라 모듈들에 대해서 functional 테스트를 작성할 수 있습니다. 윈도우즈 어플리케이션에 대해서 적당한 functional test tool을 찾을 수 없다면 passive view 같이 우리의 코드를 어떤 패턴으로 organize 할 수 있을 겁니다. 그러면 view 를 통해 action을 perform 하지 않고도 functional test를 작성할 수 있게 됩니다. 또 다른 경우를 예로 들면 C/S rich client application에서 서버가 우리가 원하는 대로 작동하는지에 대해 체크하기 위해 중요한 모듈의 functionality를 테스트 할 수 있을 겁니다.

 

- Dev unit test -> add functional tests

- Extract writing functional tests from dev to tester

 

 

 

functional test를 작성하는 것은 QA들에게는 아주 매력적인 일이죠. 개발자들에게는 unit test를 작성하는게 그럴거구요. 둘 다 동시에 진행하면 좋을 겁니다. 전체 팀의 생산성이 아주 높아지겠죠. 일단 acceptance criteria 가 확정 되면 개발자들은 unit test들을 작성하고 tester들은 functional test들을 작성하게 되는거죠. 이 방법이 이상적인 방법입니다. 하지만 실제 상황에서는 이렇게 진행되기가 힘들죠. 아래 이런 접근법에서 만날 수 있는 몇가지 문제점들을 언급하겠습니다.


가끔 개발자들과 테스터들은 동시에(parallelly) 일을 합니다. 그러면 생산성이 아주 높아지겠죠. (다시 말하지만 이러기는 힘듭니다. 이렇게 하기 위해서는 개발자와 테스터들간의 커뮤니케이션이나 iteration이 좀 더 자주 있어야 합니다.)QA가 사용하는 툴에 따라 QA가  functional test suite 를 만들고 유지보수 하기 위해 더 프로그래밍 실력이 좋아야 하는 경우도 있습니다. 만약 QA가 그렇게 프로그래밍 실력이 뛰어나지 않다면 새로 개발된 기능들에 대해 QA가 개발자를 따라잡기에 어렵습니다. 만약 개발자가 스토리를 아주 빠르게 deliver 하면 QA들의 일은 좀 더 어려워 질 겁니다.

이런 문제가 생기게 될 경우 이를 해결하는 방법이 있는데요. 그 중 하나는 개발자들에게 약간의 functional test들을 작성하고 유지 보수 하도록 하는 겁니다. 그것을 개발자의 build 에 통합하고 개발자들이 그 테스트들을 pass 하도록 하게끔 만드는 거죠.

반응형


반응형

TDD from starting from user stories - a top-down style 02

 

Pros and Cons

Pros

 

acceptance test를 먼저하면 개발자는 코딩을 시작하기 전에 value에 대해 좀 더 생각할 수 있습니다.

여러분이 무엇을 테스트할지 정확하게 이해하지 않은 상태에서 acceptance test를 먼저 만드는 것은 정말 어렵습니다. writing test first라는 룰을 곧이 곧대로 적용하도록 하면 코딩을 하기 전에 business requirement 에 대해 개발자들이 좀 더 생각할 수 있도록 도와 줄 수 있습니다. 이 접근법은 개발자들이 business analyst들이나 고객을 직접 접촉해서 business를 먼저 이해하도록 독려할 수 있습니다. 그렇게 함으로서 요구 조건을 잘 못 이해하는 경우를 줄일 수 있고 현업(business people)과 개발팀 사이의 인식 차이도 줄일 수 있습니다.

 

Test automation은 프로젝트이 시작단계에서 부터 시작해야 합니다.

 

TDD 가 acceptance test부터 시작한다는 것은 모든 테스트에 대한 automation이 그 프로젝트 그 자체임을 암시합니다. 왜냐하면 자동적으로 프로젝트를 빌드하고 테스트들을 run 하는 작업 없이 빠른 feedback을 얻기는 불가능하기 때문이죠. CruiseControl같은 integration 툴들을 사용함으로서 이런 작업을 보다 쉽게 할 수 있습니다.

 

Clear and simple design, testable code

 

전에 얘기 했듯이 story와 acceptance criteria 의 business value 를 분명하게 이해해야 합니다. 그리고 나서 그것들을 가지고 테스트를 해야 합니다. 이제 남은 일은 이 테스트들이 pass 하도록 하기 위한 가장 간단한 코드를 만드는 겁니다. 만약 writing unit tests first 가 클래스의 각 public 인터페이스의 간단한 디자인을 얻는데 도움을 줄 수 있다면 writing functional tests first 는 business value를 implement 하기 위한 가장 간단한 디자인을 할 수 있도록 도움을 줍니다.

 

 

 

Tests as documents

 

TDD를 통해 얻을 수 있는 것 중 하나는 프로젝트의 documentation 역할을 할 수 있는 좋은 test들의 세트를 가질 수 있다는 겁니다. 수준 높은 functional test들을 가진다는 것은 모두에게 businiss requirement를 이해하는데 도움을 주고 이 functional test들을 단순히 수행함으로서 어플리케이션의 functionality 를 이해하는데 도움을 줄 수 있습니다.

technical people 들만 이해할 수 있는 우리의 test들을 non-technical people들도 이해할 수 있도록 translate 해 주는 툴들도 있습니다. (Testdox 같은). rspec 같은 testing framework들은 이런 종류의 일을 지원하는 built-in 기능이 있습니다. 그리고 rbhave와 jbehave 같은 다른 프레임워크들도 business natural language에 의해 그러한 기능들을 제공합니다. 이런 일들을 통해 우리의 test들은 business value를 좀 더 제대로 반영할 수 있고 이해하기도 쉽습니다.


Delay the implementing and design decision

 

테스트들을 보고 개발자들은 implementation을 수행하고 design을 결정하는 일을 진행할 수 있습니다.

 

nurture the good habits of programming

 

개발자들은 코딩이나 기술적인 문제에만 포커스를 맞추어서는 안 됩니다. 좋은 개발자는 정말 좋은 프로그램을 개발하기 위해 도움이 될 수 있는 모든 것을 고려하는 자세를 가지고 있어야 합니다.  Agile 소프트웨어 개발 방법론은 개발자들에게 좀 더 다방면으로 능력을 발휘하기를 요구합니다. 또한 질 좋은 코딩을 할 수 있는 능력을 갖추어야 하고 무엇을 할 것인지 에 대해 개발자는 확실히 파악하고 있어야 하고 해야 할 일이 그렇게 가치가 있지 않으면 해당 requirement에 의견을 제시할 수 있어야 합니다. 간단한 디자인으로 정말 유용한 코딩을 해야 하는 거죠. Story 를 근거로 한 TDD 는 이것을 가능하도록 도와 줍니다.

 

Testing team more effective

 

개발자에 의해 만들어지고 automated 된 functional test 들로 tester들은 좀 더 효율적으로 작업을 할 수 있습니다. Tester들은 대부분의 시간을 testing에 사용합니다. performance testing, exploratory testing 그리고 manual testing 등등이 있죠. 그들은 automated test들에 의해 진행될 수 없는 그런 테스트들에 그들의 에너지를 집중할 수 있습니다. 그들은 acceptance criteria 에 좀 더 시간을 투자할 수 있고 실제 작성한 테스트 코드가 아닌 그들의 testing idea 들을 제공할 수 있습니다.

실제 현장에서 일어나는 문제 중 하나는 어떤 tester들은 훌륭한 test code를 코딩하지 못한다는 겁니다. 이 문제는 사용하는 툴이 프로그래밍을 요할 경우 문제가 되죠. 그리고 프로젝트가 점점 커질 수록 test suite들도 점점 거대해 지게 되죠. 이런 문제는 개발자들인 좀 더 많은 functional test들을 작성하면 사라질 수 있습니다.

Agile planning에서는 한개의 story 에 얼마나 많은 작업이 필요한가에 대해 계산해야 합니다. 개발자들이 functional test를 먼저 작성하게 되면 좀 더 자신감을 가질 수 있고 해당 story 가 얼마나 시간이 걸릴지 좀 더 수월하고 정확하게 계산할 수 있습니다. 그렇게 함으로서 좀 더 쉽게 계획을 작성할 수 있게 되겠죠.

 

 


Cons

 

Sometimes it’s not easy

 

TDD 스타일에 대해 여러 장점들을 얘기 했는데요. 가끔 이러한 방식이 아주 어렵다는 것을 알고 있어야 합니다. 이런 방법을 여러번 경험해봤던 사람들에게는 아주 자연스럽고 쉽게 할 수 있는 일들도 그렇지 않은 사람들에게는 처음 받아들이기에 좀 어려울 수 있습니다. 대부분의 사람들에게 TDD 는 mind shift 를 요구 합니다. 대개 개발자들은 코딩을 먼저 하고 테스트하고 문제점들을 수정하는 순서대로 개발을 해 왔을 겁니다. 이들에게 드는 의문은 어떻게 코드 없이 테스트 부터 할 수 있을까 입니다. TDD를 적용하고 실제 그에 따르려면 이 의문점부터 먼저 해결 해야 합니다. 그래야 requirement들을 반영할 test를 작성할 수 있습니다. 처음에 이 작업은 쉽지 않습니다. 하지만 이는 처음 단계에 충분히 시간을 투자해서 익힐 가치가 있습니다. 우리 스스로 배우는 자세로 가치를 우선으로 두는 소프트웨어 개발을 생각해야 합니다. 유경험자와 같이 일을 할 수 있으면 이 방법론에 좀 더 빨리 잘 접근할 수 있겠죠.

 

Story 에서 TDD를 진행하는 방법은 몇가지 전제조건들이 충족 되어야 합니다.
첫째로 좋은 story 가 준비 되야 합니다. 좋은 story는 독립적이고 가치가 있고 예측할 수 있고 작고 테스트가 가능한 스토리여야 합니다.
좋은 스토리가 있으면 개발자들은 business value를 훨씬 쉽게 이해할 수 있고 좋은 question들을 제기할 수 있습니다.
그리고 작고 테스트가 가능해야 하는데요. 그래야 적정 시간 안에 writing test first 를 하면서 일을 끝낼 수 있습니다.


두번째로는 각 스토리에 대한 acceptance criteria 들이 분명해야 합니다. 그래야 개발자들이 그것을 근거로 쉽게 test들을 개발할 수 있습니다.
좋은 스토리는 성공적인 프로젝트의 corner stone 입니다.

 

Difficult in some areas like cpp, game, restricted by the availability of tool set

 

이 접근법에 대해 얘기 한 것 중 중요한 한가지는 좋은 functional testing tool을 갖는 겁니다. 실제 프로젝트에서 가끔 여러분의 어플리케이션에 맞는 좋은 functional testing tool을 찾는 것은 아주 어려울 수 있습니다. 여러분이 사용하는 프로그래밍 언어와 어플리케이션이 돌아갈 플랫폼 혹은 프레임워크에 따라 좀 더 어려워 질 수도 있습니다. 예를 들어 Windows desktop 어플리케이션을 위한 딱 맞는 툴을 찾기는 어렵습니다. QTP는 놓은 툴인데요 TDD에는 좀 무거운 감이 있습니다. 다른 예로는 게임이 있습니다. C나 Cpp를 사용하는 게임 프로젝트에는 TDD를 적용하기가 어렵습니다.

툴들도 진화합니다. 몇년전에는 웹 어플리케이션을 위한 툴을 찾기도 아주 어려웠습니다. 하지만 요즘은 웹 어플리케이션 functional testing을 위한 툴들은 아주 많습니다. 필요하게 되면 사람들은 좀 더 좋은 툴을 만들게 될 겁니다.

 

Build will get slow if not being careful because functional tests number increases


신경쓰지 않으면 Build 는 slow하게 될 겁니다. 왜냐하면 functional test들의 숫자가 증가하게 될 테니까요.

정의 하자면 functional test는 소프트웨어의 실제 functionality를 테스트 하는 겁니다. functional test에서는 대개 database들에 접근하고 네트워크를 통해서 데이터를 전달하고 파일을 읽고 쓰는 일 등등을 하게 됩니다. 일반적으로 발생하는 문제점 중 하나는 프로젝트가 점 점 커가게 되면 이런 모든 functional test들을 running 하는데 걸리는 시간이 훨씬 더 길어지게 된다는 겁니다. 이렇게 되면 functional test로부터 feedback을 빨리 받을 수 없게 되죠. 그리고 팀의 생산성도 떨어뜨립니다. 그러면 개발자들이 의도하지 않는 테스트들을 돌리고 의도하지 않는 functional test들을 작성하도록 만듭니다.

 

가끔 실제로 프로젝트를 진행하다가 그런 상황을 맞게 되는데요. 대부분 그 문제를 해결하기 위한 여러 해결방법들을 찾을 수 있습니다. 혹은 그냥 skip 할 수도 있죠.
예를 들어 개발 중에 functional test들을 작성하고 실행시킬 때 check in 하기 전에 모든 테스트들을 미리 run 해 볼 수 있습니다. 필요하면 테스트들을 좀 더 작은 group으로 나눠서 그 그룹들을 parallel 하게 돌릴 수도 있죠. 또한 우리의 테스트들을 reorganize할 수도 있고 stub과 mock을 사용해서 실제 외부 시스템에 접근하지 않고 테스트를 하도록 할 수도 있습니다.

반응형


반응형

TDD 프로젝트에 참여하면서 정말 많은 것들을 배우고 있습니다.

새로운 프로젝트에 익숙해 지느라 블로그 포스팅을 오랫동안 못 하고 있는데요.

 

배우는 것들을 다 정리를 해 두지는 못하더라도 가능한대로 그때 그때 블로그에 정리를 해서 한번 배울때 더 확실히 이해하고 다음번에 같은 일을 할 때 좀 더 편하고 깊게 작업을 해서 점점 더 훌룡한 프로의 모습을 갖춰가고 싶네요.

 

또 그 글을 이렇게 공개된 블로그에 정리해 두면 다른 분들에게도 도움이 될 수 있을 것 같구요.

 

일단 개념 정리부터 하겠습니다.

 

써핑하다가 좋은 글을 발견해서 그 글 부터 정리해 둘 까 합니다.

 

http://exceedhl.thoughtworkers.org/Programming/2007/08/02/tdd-a-top-down-style.html

 

영어 되시는 분은 위 링크 가서 직접 보시면 좋을 거예요.

2007년도에 작성한 글이네요.

 

한번에 다 정리하지는 못하고 여러번에 나눠서 정리해야 될 것 같네요.

 

 

TDD from starting from user stories - a top-down style

반응형

새 프로젝트에 Join....

2013. 5. 6. 02:14 | Posted by 솔웅


반응형

새로운 프로젝트에 투입되면서 모바일 쪽이랑은 완전히 멀어졌어요. T_T

 

지금은 은행쪽 프로젝트를 하고 있습니다.

한달동안 무지 헤맸는데 이제 조금씩 자리가 잡혀가고 있는거 같아요.

 

저는 Testing team 에 속해 있습니다.

현재 프로젝트에 TDD (Test Driven Development) 개념을 도입시키려고 하는데... 실제 일 시키는거 보면 그것 보다는 일단 JUnit 으로 TestCase 들 만드는게 주 일 입니다.

 

한달동안 일하면서 들었던 여러 용어들을 일단 적어 놓으려구요.

아마 이번 프로젝트 하는 기간에는 이 용어들과 관련된 기술에 대한 글들을 위주로 블로깅을 할 것 같네요.

 

 

 

 

- 프레임워크는 기존 Struts 프레임워크를 사용하는 애플리케이션들이 있고 새로 만드는 애플리케이션들은 Spring을 사용할 것임

- LLD (Low Level Degien) 문서를 근거로 JUnit 으로 TestCase를 만듬

  그런데 지금까지는 TDD 개념을 프로젝트에 적용하지 않아서 이 부분이 미진함.

- JUnit, JWebUnit, Soup UI 등의 테스팅 툴들을 사용할 것임

- 애플리케이션 단에서 Web Service 와 연계된 메소드들을 테스트 하기 위해서는 Mockito, inject 를 사용함

- Web Service 테스트는 Soup UI 로 함

- JWebUnit 은 UI 단 테스트의 Automation 을 위해 사용함

- 그 외 Functional Testing, Acceptance Testing 등을 진행 함

- Mobile을 위한 어플리케이션도 있는데 이 부분은 Struts를 사용함

- IDE 는 JBoss Studio 4.0 을 사용함 (Eclips 와 거의 같음)

- Maven 으로 Dependancy 관리 함

- MKS Integrity 에서 소스파일 관리를 함

- JDK 1.6 을 사용함

- Oracle 11G를 사용함

 

일단 기억나는 것들은 이런 것들 입니다.

 

 

 

앞으로 이 프로젝트가 끝날 때까지 이와 관련된 기술들을 깊이 공부할 생각입니다.

프로젝트가 은행 온라인 뱅킹 관련 프로젝트인데요.

이곳 온라인 뱅킹은 한국의 은행 온라인 뱅킹이랑 조금 다른점이 있는거 같아요.

 

새로운 분야를 공부할 좋은 기회입니다.

 

프로젝트 기간이 6개월이니까 최소한 그 기간동안은 이쪽에서 사용되는 기술이나 개념을 익히는게 우선이겠네요.

물론 관심이 있는 모바일 쪽도 계속 공부는 할거지만요.

 

 

여기 캘리포니아 쪽에서 모바일 인력 필요하신 분들은 연락 주세요....

뭐든지 배우려면 실무를 하면서 배우는것이 더 효율적이잖아요.

 

다음 프로젝트는 모바일쪽을 하고 싶네요....

 

여기도 모바일쪽과 연관된 분야가 있으니 그쪽 일을 좀 더 많이 맡아야겠어요.

 

지난달에는 거의 글을 못 올렸는데요.

아마 당분간 여기 일이 익숙해 질 때까지는 글 올리는 일이 힘들 것 같습니다.

 

일이 익숙해 지면 계속 공부하면서 글 올리겠습니다.

반응형