하지만 log 역시 좀 갑갑한 느낌 들지 않나요?
Debugger는 중단점을 이용하는데 이거 button누르는게 귀찮아서 하는 이야깁니다. ^_^
Debugging 방법은 다양하게 있겠습니다만 제가 묻는 것은 Debugger를 활용하는 방법에 가까운 상황을 이야기하는거죠.
특정식이 어떤 상황에 왔을 때 중단하고 그 순간부터 지적한 구간의 속도를 한 1/10000배쯤 느리게 해서 천천히 상태들이 변화하는 것을 관찰할 수 있다면 좋겠다는 생각이 들었어요.
단위 testing 기법은 그것이 whitebox test 이든 blackbox test이든 각 action 사이를 관찰한다는 점에서 다를 바는 없는 것 같아요. Module을 잘게 쪼개서 module 단위로 관찰하면 blackbox test이고 원래 module 내에 관찰시점을 끼워넣으면 whitebox test이고 말이죠.
이건 어찌보면 함수형 언어 관점이 아닌가라는 생각이 들었습니다. 입력이 있고, 출력을 확인한다는 점이 말이죠.
Debugging을 객체지향으로 본다면 내가 원하는 모든 상태들이 시간의 흐름에 따라 변화하는 것을 바라볼 수 있어야 하지 않을까요?
...
valgrind를 물려서 돌리시면 어떨까요. 50배 정도 느려진다고 쓰여 있던 얘기가 떠오릅니다. 혹은 잘 알려진 speedhack류의 프로그램을 구하셔서 배속을 줄이시는 것. 또는 Vmware, Virtual Box류의 가상 머신에서 돌리기 등등...
어차피 순차적으로
어차피 순차적으로 진행되는데 로그를 뜨면 되지 않을까요 - _-);;
제가 생각하는 가장 가까운게 log 이긴 하죠.
하지만 log 역시 좀 갑갑한 느낌 들지 않나요?
Debugger는 중단점을 이용하는데 이거 button누르는게 귀찮아서 하는 이야깁니다. ^_^
Debugging 방법은 다양하게 있겠습니다만 제가 묻는 것은 Debugger를 활용하는 방법에 가까운 상황을 이야기하는거죠.
특정식이 어떤 상황에 왔을 때 중단하고 그 순간부터 지적한 구간의 속도를 한 1/10000배쯤 느리게 해서 천천히 상태들이 변화하는 것을 관찰할 수 있다면 좋겠다는 생각이 들었어요.
단위 testing 기법은 그것이 whitebox test 이든 blackbox test이든 각 action 사이를 관찰한다는 점에서 다를 바는 없는 것 같아요. Module을 잘게 쪼개서 module 단위로 관찰하면 blackbox test이고 원래 module 내에 관찰시점을 끼워넣으면 whitebox test이고 말이죠.
이건 어찌보면 함수형 언어 관점이 아닌가라는 생각이 들었습니다. 입력이 있고, 출력을 확인한다는 점이 말이죠.
Debugging을 객체지향으로 본다면 내가 원하는 모든 상태들이 시간의 흐름에 따라 변화하는 것을 바라볼 수 있어야 하지 않을까요?
이유가, next, step
이유가, next, step 명령을 반복하는게 귀찮다는 것이라면, 반복 횟수를 지정하거나, condition을 추가한 breakpoint, advance, until 등의 명령을 쓰면 됩니다. (GDB인 경우)
참고: Breakpoints & Data Dumping
--
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://www.cinsk.org/cfaqs/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/
profiler로는 해결이
profiler로는 해결이 안되는 문제인가요?
또한 인위적으로 느리게하면 또 다른 문제를 불러들이는 수가 있습니다.
다시말해 미묘한 타이밍 문제의 경우 멀쩡하게 돌던 프로그램도 시스템의 하드웨어나 OS/Framework등의 library 관련 layer가 변경되면 치명적 오류가 발생하는 상황도 본적이 있습니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
댓글 달기