'Developer'에 해당되는 글 400건

  1. 2010/06/07 mock vs stub (1)
  2. 2009/09/06 단위 테스트를 습관화 시키기 (1)
  3. 2009/04/01 새로운 코드 개발하기와 기존 코드 이용하기
  4. 2009/03/28 진정한 개발자...그리고, 월급쟁이 개발자 (10)
  5. 2009/03/21 어느 개발자의 생각
  6. 2009/03/19 지식 공유를 위한 좋은 방법은 없을까? (4)
  7. 2009/02/19 clean code 이야기
  8. 2009/01/29 clean code (3)
  9. 2009/01/01 새해복많이 받으세요 & 네이버 메인 개편 축하
  10. 2008/12/12 개인도메인(pe.kr) 무료 제공 이벤트 (2)

mock vs stub

Developer
2010/06/07 23:18
개념만 이해를 하고 있고, 설명을 하려니 그림/표가 부족해서 정리 잘 된 문서 몇개 정리를 해봤다.



mock

mock object http://www.c2.com/cgi/wiki?MockObject

mock aren't stubs http://martinfowler.com/articles/mocksArentStubs.html

mock roles, not object http://www.jmock.org/oopsla2004.pdf

mock vs stub

http://weblogs.asp.net/rosherove/archive/2007/09/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.aspx
  • Stubs provide input for the application under test so that the test can be performed on something else.
  • Mocks provide input to the test to decide on pass\fail. the opposite direction.

image 

A stub can never fail a test.


xunit patterns http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html

Terminology Cross-Reference

I'm listing some sources of conflicting definitions just to make it clear what the mapping is to my pattern names:



Sources and Names Used in them
PatternAstelsBeckFeathersFowlerjMockUTWJOMGPragmaticRecipes
Test Double






Double or stand-in
Dummy ObjectStub


Dummy


Stub
Test StubFake
FakeStubStubDummy
MockFake
Test Spy




Dummy

Spy
Mock ObjectMock
MockMockMockMock
MockMock
Fake Object




Dummy


Temporary Test Stub




Stub


OMG's CORBA Stub





Stub

태그 mock
트랙백 0 : 댓글 1

단위 테스트를 습관화 시키기

Developer
2009/09/06 20:37
단위 테스트의 중요성을 인식하고 여러 개발자들과 얘기를 하고 pair개발도 했지만, 대부분의 개발자는 아직까지 단위 테스트 개발에 어려움을 많이 느끼는 듯하다.

개발에 대한 품질에 대해서 항상 고민하는 개발자들은 알아서 실천을 하고 있지만, 보통 개발자 이하인 사람들은 교육을 시키고 코칭을 해도 적용을 못하고 있다.

어떤 부분이 그들에게 넘지 못하는 산이 되고 있을까?

제일 큰 부분은 동기부여일 것이다. 이 부분은 가장 어려운 문제중에 하나이다. 동기부여는 너무 개인적인 요소들이 강해서 하나의 주제로 드라이빙을 하더라도 다른 사람들에게는 매력적인 요소가 되지 않을 수도 있다.

지금까지 내가 전달한 동기부여에 대해서 큰 의미를 주지 못했다면, 다른 방법을 생각을 해봐야겠다.
좋은 의견이나 성공한 케이스가 있으면 덧글 달아주세요~^^


트랙백 0 : 댓글 1

새로운 코드 개발하기와 기존 코드 이용하기

Developer
2009/04/01 19:12
개발자가 코드를 개발을 잘하는 것은 당연히 갖추어야 할 능력이다.

새로운 코드를 개발을 할때 다른 이들이 사용을 할수 있는 인터페이스를 만들어야 할때 많은 정성을 기울여야 하고, production code로 올라간 뒤에 유지보수를 잘 해야 한다.고객이 원하는 요구사항과 인터페이스를 추가하는 일은 그 중에 가장 중요한 요소이다.

또 하나의 중요한 능력은 다른 개발자의 좋은 코드를 잘 이용을 하는 것이다.

어떻게 하면 잘 이용을 할수가 있을까?

1. 다른 개발자들이 만든 production과 code를 관심있게 봐야 한다.
요구사항이나 필요성을 느꼈을 때 무작정 개발을 시작하는 것 보다는 선배님들이 주위에 개발자들이 만든 코드들을 살펴보는 것도 중요하다.

2. 적용전략을 골라야 한다.
예를 들면, 직접 의존을 걸어서 쓸 것인지, 한번 wrapping(delegation)을 해서 사용을 할 것인지에 대한 이슈에대한 결정은 선택에 따라서 추후에 발생할 비용은 차이가 많다. 물론, 2가지 방법 다 장단점이 있다.
태그 개발자, 중복코드, 코드작성
트랙백 0 : 댓글 0

진정한 개발자...그리고, 월급쟁이 개발자

Developer
2009/03/28 15:09
나도 월급을 받으면서 개발을 하는 사람 중에 하나지만, 내가 하는 일에 있어서 금전적인 잣대를 가장 우선시에서 생각을 한적은 없다.(아니..가끔 있을 수도 있다)

금전적인 문제에 100% 자유로울 수는 없지만, 개발자로서 이루고 싶은 품질이나 목표. 비젼이 있는 사람은 동반자로서 받아 들이기 아주 쉬운 경우이다. 이런 부류를 "진정한 개발자"라고 부르겠다.

내가 어렵게 느끼는 사람 중에 하나는 개발자체에 흥미를 가지지 못하는 사람이다.
개발자가 자신의 하는 일에 만족도가 무척 떨어진고, 먹고살기위해서 어쩔 수없이 해야 한다는 생각만을 가진 사람에게 어떤 얘기를 해줘야 하며, 어떤 비젼을 공유해야 할 것인가?

개발에 흥미가 없는 사람에게 개발관련된 일이란 노가다일 뿐이고, 새로운 도전은 피곤한 일상이 될 것이다. 이런 부류를 "월급쟁이 개발자"라고 부르겠다.

진정한 개발자와 월급쟁이 개발자 사이에는 분명히 다른 비젼들이 존재하기때문에 같은 이슈를 해결을 할때도 크게 다른 방법으로 처리를 한다.

우리가 아는 모든 레퍼런스들은 대부분 진정한 개발자라고 가정을 하고 얘기들을 하지만, 그렇지 않은 월급쟁이 개발자도 있는 것이다. 주위의 모든 개발자들이 "진정한 개발자"라면 좋겠지만, 아닌 사람들도 많다.

하지만, "월급쟁이 개발자" 부류들도 버릴 수 없는 우리의 동료들이다. 그 부류들도 너무 힘들지 않을 정도의 프로세스로 "월급쟁이 개발자"에서 "진정한 개발자"와 유사한 형태로 만들어 주는 것은 아주 중요한 일이다.

근본적인 사상으로 올라가다가 보면, 세상의 모든 일이 비슷하다.
열심히 일하는 사람과 일하지 않는 사람..그로 이해서 생기는 빈부의 격차..이건 포기할 수 없는 문제이다. 가난한 사람도 이끌어 가야할 이 시대 구성원이기때문이다.


태그 개발자
트랙백 1 : 댓글 10

어느 개발자의 생각

Developer
2009/03/21 22:32

개발자라는 직업을 가지고 일한 것도 꽤나 오랜 시간이 흘렀다.

수만은 개발자들을 만나왔고, 앞으로도 수많은 개발자들을 만날 것이다.

뒤돌아 생각을 해보면, 내가 만난 사람들은 다행스럽게도 에너지가 가득하고, 좋은 마음을 가진 사람이 많은 편이라 힘들지 않게 지내왔던거 같다.

각각의 개발자들 모두와 깊게 얘기한 것은 아니지만, 개발자들 사이에서도 불신이라는 것이 저변에 많이 깔려있는 경우가 있다.

또한, 자신만 불이익을 당하고 있다고 생각을 할 수도 있고, 모든 사람이 나처럼 바보같이 살 것이라는 생각을 할 수가 있다.

주위를 조금 더 관찰하면서 살펴보면, 꼭 그런 경우가 아닐 경우가 있다. 자신의 경험을 전체에 확대하는 것은 위험한 일이다.

나도 "hello, world"를 처음 찍을 때를 생각하면서, 동반자로서의 마인드를 좀더 깊게 생각하겠다.
한번더..한번더...성장을 할수 있는 기회가 주어진 것인가?

태그 개발자, 생각
트랙백 0 : 댓글 0

지식 공유를 위한 좋은 방법은 없을까?

Developer
2009/03/19 11:27
서비스를 운영하다가 보면, 히스토리라는 것이 생긴다.

코드를 개발하다가 보면, 좀더 나은 코드의 pattern이 생긴다.

시간이 흐르면서 강건하게 만들어지는 이런 규칙들을 새로운 사람들과 쉽게 공유를 할 수 있는 방법은 없는 걸까?

하나의 장소에 오래 머물러 있기도 어렵지만, 새로운 장소에 있을 때 빨리 그 장소에 맞는 규칙들을 빠르게 습득하게 할수 있는 방법이 필요하다.
태그 시간은흐른다
트랙백 0 : 댓글 4

clean code 이야기

Developer
2009/02/19 08:46
clean code
 
제 생각은 그렇습니다. 코드를 유지보수하거나 신규로 작성을 하다가 보면 항상 선택이 순간들을 맞이 하게 됩니다.

이 때, 대부분의 개발자들은 욕심을 가지게 됩니다.(물론 저도 자주 그래왔구요...^^;)
 
 
 
욕심...이것을 잘 통제해야 합니다.
 
1. 테스트 커버리지를 높이고 싶은 욕심에 테스트가 필요없는 메소드를 테스트를 만들어서 테스트 유지보수를 더 힘들게 하는 경우도 있습니다. 정말 만들어야 하는 부분은 반드시 만들어야 하는 것이 테스트 코드지만, 작성시에도 적은 코드량으로 테스트를 만들 방법을 고민해야 합니다.
 
2. 내가 만든 코드들이 지나친 일반화나 강제화때문에 사용하는 개발자들이 불편해 합니다. 세부적인 영역의 내용들은 캡슐화를 통해서 적게 보여야 정확한 비즈니스 로직이 보입니다.
 
 
 
선택의 순간
 
설계를 하다가 선택의 순간이 왔을 때 가장 중요한 것은 무엇일까요?
 
신규 코드를 작성하거나 코드 개선시에 제가 중요하게 생각하는 요소는 다음과 같습니다.
 
1. SAFE and SAFE: 솔루션이던지, 서비스던지 첫째는 안정적이어야 합니다.
 
2. 중복제거
중복의 해악에 대해서 다들 아시겠지만, 중복이라는 것을 발견하는 sensing이 필요합니다. ex) 코드 중복, 로직 중복, 라이프싸이클 관리 중복 등등
블로그같은 경우의 예를 들어보죠. 프레임워크 중복, 프로젝트의 중복, 코드상의 중복, dependency의 중복.
중복이 없게 아키텍쳐를 설계하거나 코드를 작성을 하다가 보면, 좋은 디자인이 나오는 경우가 많습니다.
 
2. 가독성(composed method, good naming, etc)
 
3. 의존성 최소화
cyclic의 방지
테스트 작성의 용이함
변경시에 영향도 최소화
 
현재 상태에서 고민을 해봅시다.
프레임워크를 변경(자주 일어나는 일은 아니지만 아예 없는 일은 아니죠?) webwork에서 struts2.0으로 간다면? spring에서 google juice로 dependency framework를 변경한다면?
외부 라이브러리들이 버젼이 올라가면서 하위버젼을 지원하지 않는 경우가 많다면?
클래스의 인터페이스를 변경해야 한다면? 
 
4. 성능(구현 후 tuning을 하는 것이 설계시 덜 헷갈립니다.)
 
 
 
긍정적인 마음 
 
 
실무에서 정확한 판단을 하기는 쉽지 않습니다. 잘못된 구현이나 판단을 할수도 있습니다.
 
항상 베스트 프랙티스로 만드는 사람들은 훌륭한 개발자라기보다는 훌륭한 예언가일 것입니다.
 
결국엔 점진적으로 더 나은 방향으로 개선을 해야겠다는 에너지와 의지가 더 중요할 수 있습니다. 노력을 한다면, 좋아 질수 있습니다.
태그 clean code
트랙백 3 : 댓글 0

clean code

Developer
2009/01/29 00:52
우리는 developer이지만, author이기도 하다.
clean code라는 말은 정말 쉬운 단어로 이루어져 있지만, 우리가 코드를 작성할 때 어떤 마음가짐으로 해야 하는 것을 알려주는 강력한 말이다.

clean code책을 초반부를 보고 있는데 보면서 계속 켄트벡형님의 implementation pattern이 생각이 났다.

2개의 책은 마이크로 패턴(?)에 대한 이야기다.

위대하고, 훌륭한 설계에 대한 이야기를 하는 것보다는 개발자가 코드를 작성하면서 생각해야 하는 기초적인 사고들을 이야기하고 있다.

implementation pattern은 표현이 축약적이고, 코드없이 설명을 해서 나에 경험에 비추어서 다시 생각을 하게 되는 반면에 clean code는 일부는 실제 코드로 보여준다. 그래서 저자의 의지의 표현에 좀더 쉽게 다가갈수 있다.

최근 나는 복잡한 시스템에서 거대한 디자인보다 좀더 세밀하고 작은 영역의 코드,패턴들에 관심을 많이 가지고 있는데, 이 책은 나의 생각들을 잘 표현을 해주었고, 더 나은 생각들을 할수 있게 도움을 주고 있다.



clean code는
- 독자를 고려한 코드를 작성해서 읽기가 쉽다.
- 불필요한 중복이 없다.
- unit  testing이 쉽다.

더 나은 개발자가 되기 위한 노력의 시작은 clean code, implementaiton pattern을 읽기 시작하면서부터 이루어질 것이다.


Clean Code (Paperback / 1st Ed.)

Martin, Robert C. / Prentice Hall



트랙백 2 : 댓글 3

새해복많이 받으세요 & 네이버 메인 개편 축하

Developer
2009/01/01 11:06
2009년은 좋은 날씨로 새해를 맞이했네요.

2008년에는 세계경제의 충격으로 자산가치의 하락으로 어렸웠던 분들이 많았습니다.

2009년에는 경기가 회복이 되면서 좋은 일이 많이 생기길 바랍니다.

정말 많은 분들이 애를 쓰셔서 네이버메인이 개편이 되었는데, 메인 개편을 비롯한 오픈캐스트에 대한 반응이 좋았으면 하네요.

오픈 이후에 지금까지 보았을 때 별다른 장애나 문제는 없어 보이네요. 그 동안 애많이 쓰셨습니다....^^


트랙백 0 : 댓글 0

개인도메인(pe.kr) 무료 제공 이벤트

Developer
2008/12/12 19:00













네이버에서 개인도메인(pe.kr) 무료 제공 이벤트 진행중입니다.

관심있으신 분들 하나씩 가져가세요~

http://section.blog.naver.com/event/DomainPromotionEventForm.nhn
태그 개인도메인
트랙백 0 : 댓글 2
◀ PREV : [1] : [2] : [3] : [4] : [5] : ... [40] : NEXT ▶
BLOG main image
OOP and Java by ologist

공지사항

카테고리

All (649)
private!! (106)
WEB & IT (140)
Developer (400)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

meet me at meet me at me2DAY

Tattertools

rss