Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- ComponentScan
- Spring/JAVA 서적
- 미니미프로젝트
- Solid
- DB
- java
- ATDD
- 완벽이해
- Be
- hateoas
- 자식객체
- 마이크로서비스디자인패턴
- Java 22
- docker
- 도커
- 부모객체
- testdrivendevelopment
- M:N
- pair programming
- TDD
- GC
- KPT
- 클린코드
- 스프링으로하는마이크로서비스구축
- G1GC
- RESAPI
- Execution Engine
- Runtime Area
- Self Descript Message
- 트랜잭션 격리 수준
Archives
- Today
- Total
목록testdrivendevelopment (1)
Programming Summary
방법론) TDD를 할까? 말까?
들어가기 전에일단 난 TDD를 할 능력도 안되고, 사수 개발자가 Test를 먼저 짜주어도 그걸 구현할지도 미지수이다.(우테캠 2차 과제테스트때 거의 구현하지 못했다) 그래도 나에게 TDD를 구현할 능력이 충분히 있다면 그때 TDD를 적용시킬 지에 대한 토론을 진행해보고자 한다.TDD 찬성!선배 개발자가 이끌어주기 좋아!잘하는 선배 개발자가 테스트를 만들어주면, 후배 개발자는 이 테스트를 다 통과하는 코드만 작성하면 된다. 바로 알고리즘 구현 문제가 되버리는 거다. 난이도가 아주 높겠지만..테스터의 입장까지 고려해볼 수 있어!코드를 먼저 짜고 테스트를 작성한다면 코더의 입장으로 작성할 수 밖에 없다. 그러나 테스트를 먼저 작성하면 테스터의 입장으로 작성할 수 있어, 더 많은 테스트 케이스를 고려해볼 수 있..
프로 디지털 아카데미 4기
2024. 7. 12. 14:33