node.js는 브라우저에서 동작하지 않기 때문에 디버깅을 돌리기 위해서는 도구가 필요합니다. 이클립스에 node.js 플러그인을 깔아서 하는 방법이 있고, node-inspector 도구를 이용하는 방법 두 가지가 있습니다. node-inspector는 크롬브라우저를 독립적으로 띄워서 크롬 인스펙터처럼 디버깅 할 수 있게 합니다.


설치

npm install -g node-inspector


node-inspector 명령이 위와 같이 설치되면 node.js 로 만들어진 프로그램을 디버그 가능한 모드로 실행합니다. 다음과 같이 node.js를 두 가지 디버그 모드로 실행할 수 있습니다. 5858 포트를 엽니다.



디버그 모드 실행

node --debug ex.js

실행 처음에 브레이크포인트 적용된 모드로 실행
node --debug-brk ex.js

다른 명령창에서 node-inspector 를 실행합니다.

node-inspector 

크롬브라우저가 따로 뜹니다.

http://localhost:8080/debug?port=5858 주소를 이용합니다.



브레이크포인트를 잡으면 실행시 디버그가 가능합니다. 변수의 메모리를 확인할 수 있고, Console탭을 통해서 this 등의 키워드가 가르키는 내용도 확인이 가능합니다. 실행된 변수 위에 마우스를 올리면 내용을 풍선도움말로 띄워서 보여줍니다.


만약 디버그모드로 떠 있는 node.js 가 없다면 다음과 같은 메시지를 보게 됩니다.



전체적인 구조는 다음과 같습니다.



관련 링크: 

node.js debug: 

http://nodejs.org/api/debugger.html


node-inspector 

https://github.com/node-inspector/node-inspector#node-inspector




아이폰엔 있습니다. 이런 괴물... 이미지 상단에 "콘솔 디버그 오류 없음" 이라고 보입니다.

설정에서 브라우저 정보에 보면 개발자용이라고 표시됩니다.

콘솔 디버그 옵션을 활성화하면 됩니다.

오류가 생긴 경우 더 자세한 정보를 볼 수 있습니다.

HTML/JavaScript/CSS 의 오류가 보여집니다.

모바일웹 개발시 유용하게 쓰일 것 같습니다.



이 글을 포스팅하려는데 3.0.4 업데이트가 나왔군요. ^^

firebug의 업데이트와 함께 새로운 UI의 옵션이 맨 처음에 나옵니다.
콘솔(Console), 스크립트(Script), Net 기능을 체크해야 자바스크립트와 네트워크 관련 기능을 사용할 수 있습니다.

이 중에서 콘솔은 자바스크립트 에러가 표시되는 화면입니다. 다음과 같이 표시됩니다.

여기서 에러메시지를 클릭하면 해당 소스의 자바스크립트로 이동하게 됩니다.

콘솔에는 다른 기능도 있습니다. 바로 현재 페이지의 자바스크립트를 편집해서 실행할 수 있는 영역이 있다는 것입니다. 콘솔 탭의 하단에 >>> 프롬프트 라인입니다. 여기에 자바스크립트를 넣어서 실행할 수 있습니다. 예전부터 있었는데, 안 썼습니다. 몰랐으니까요. ^^;

이렇게 실행 결과도 확인할 수 있습니다.

편집 영역을 확장할 수도 있습니다. 라인 우측의 회색 동그라미를 클릭하면 다음과 같이 넓어집니다.

Ajax 작업을 할 때 작은 프로그램도 여기에 넣어서 실행이 가능합니다. ^^;

 
해킹에 조심하셔야겠어요. 툴은 중성이죠. 사용하는 사람에 따라 선이 될 수도 악이 될 수도 있으니까요. 중요한 로직 체크는 자바스크립트로 하는 것을 피해야죠. 서버 쪽의 프로그램에서 체크하는 것은 웹개발의 기본이겠죠.

춤추러 갑니다. ^^ 스윙댄스요. ㅎㅎ



http://findbugs.sourceforge.net 메릴랜드(Maryland) 대학에서 공개한 도구입니다. 자바의 버그패턴에 맞춰서 자바 소스코드를 컴파일된 바이트코드로 정적 분석한 후에 어느 부분이 문제가 되는지 자동 리포팅해줍니다.
누군가 내 코드를 검사한다는 것이 개발자에게는 탐탁치 않지만 임신진단시약처럼 자가테스트를 한다면 다른 얘기가 되겠죠. 남에게 보이기 전에 자신의 코드를 깔끔하게 만들 수 있으니까요.

그러나 바쁜 현대인을 위해서 지속적인 통합툴에서 대신해 주기도 합니다. (참고: http://www.ibm.com/developerworks/kr/library/tutorial/j-cq11207/section11.html )

이클립스 플러그인도 있습니다. findbugs의 수많은 옵션을 알지 못해도 간단하게 마우스 버튼으로 조작해서 사용할 수 있습니다. (참고: http://findbugs.sourceforge.net/manual/eclipse.html )

QA역할을 하는 동료가 짐을 덜었다고 좋아하던데, 자기가 짠 코드의 결함 검사는 스스로하는 것이 바람직할 듯 합니다. 경기 후 어지러진 관중석을 보는 듯한 코드는 으윽 이니까요.
사용자 삽입 이미지

아주 올드한 디버깅 자바부터 제가 갖고 있는 책은 7권 정도 됩니다.
디버깅 자바: 버그 잡는 방법에 대한 일반론부터 정책들까지 다뤄집니다. (2000년 번역)

실용주의 프로그래머를 위한 단위 테스트 with JUnit : 가장 얇습니다만 굉장히 실용적입니다. (2004년 번역)

이클립스 기반 프로젝트 필수 유틸리티 : 국내 최초의 협업을 주제로 한 책입니다. JUnit과 Ant의 랑데뷰가 그려집니다.(2004년)

테스트 주도 개발 : 이게 다 이 책 때문입니다. (2005년 번역)

지름길로 빠르게 배울 수 있는 자바 프로그래밍 : 미스테리한 책입니다. 일단 출판사가 교학사, 뚜시쿵!!! 원제는 Agile Java : Crafting Code With Test-Driven Development. 아하! 그럴만 하겠죠. 자바 기초 서적인데 Hello World 나오기 전에 JUnit부터 나옵니다. 말 다했죠. (2005년 번역)
Unit Testing In Java : 2004년에 사서 아직도 다 못 봤습니다. UI, 웹, 동시성 등 다양한 영역에서 테스트 방식을 알려줍니다.

Working Effectively With Legacy Code : 작년 11월에 사서 아직도 2/3밖에 못 읽었습니다. 혹자의 서평이 이 책은 TDD의 실무 적용판이다라고 적절하게 하신 듯 합니다.

이 외에도 더 있습니다. 기억이 나거나 습득하게 되는 대로 계속 포스팅하고 싶습니다. ^^
테스트만큼 번잡스러운 것이 없습니다. 모두가 동의하는 것은 테스트를 많이 할 수록 버그는 많이 발견된다는 것인데, 문제는 테스트하기가 귀찮다는 것이죠.
6월 14일 발표하는 자료에서 이런 고민에 대한 저의 생각을 풀어볼 생각입니다.
사용자 삽입 이미지


첨부파일은 freemind(http://freemind.sourceforge.net) 마인드 맵 원본입니다.

이클립스 콘솔뷰에도 좋은 기능이 있습니다. 바로 resource연결입니다. 스택트레이스 같이 예외 메시지가 뿌려질 때 java파일일 경우 에러난 위치를 바로 보여줍니다.
모든 경우 적용 되는 것은 아닙니다만 똑똑해진 Open Resouce와 연결되면 편리하게 디버깅이 가능합니다.

WTP를 통해서 톰캣을 시작하면 콘솔뷰에 시스템 로그가 남습니다. 또 볼 수 있구요.
제 사이트를 돌려 보는 중에 메시지가 눈에 띄었습니다.

console log

console log


try catch에서 잡은 로그 메시지인 듯합니다. MemoServlet:... 로그가 보이는군요. 엇, 링크까지.
클릭해봤습니다.
Source not found

Source not found


Source not found for MemoServlet:java.lang.NumberformatException 라고 나옵니다.
보통 이쯤 되면 ctrl+shift+R을 눌러서 파일을 찾겠지만, 잠깐!
MemoServlet 글자를 마우스로 드래그해서 선택해보시죠. 그리고, ctrl+shift+R 를 하시면 다음과 같이 착하게 나옵니다.
Open Resource after text selection

Open Resource after text selection

착합니다. ^^ 파일을 열어서 살펴보겠습니다. 아마 이 부분인 듯 합니다.
review source

review source

디버깅을 해보니 || 가 아니라 && 이 되어야 되는군요.

^^ 요기까지입니다.
JSP 디버깅은 환경설정이 거의 반을 차지합니다. eclipse WTP 에서 JSP 개발환경을 구축하는 것은 따로 설명하겠습니다. 일단 이 환경만 구축이 되면 JSP디버깅은 java 디버깅과 크게 다르지 않습니다.
디버깅은 JVM내부를 들여다 볼 수 있어야 합니다. eclipse WTP에서 WAS를 구동하게 되면 WAS의 메모리를 들여다 볼 수 있습니다. 이것에 기반하여 JSP 가 돌아가는 WAS의 메모리 값을 확인하는 것이 기본입니다.

jsp project

jsp project

debugjsp 라는 프로젝트를 만들었습니다. 프로젝트 아이콘을 보시면 debugjava 프로젝트와 다른 것을 알 수 있는데, 조그마한 지구 모양과 J 모양은 웹 관련 java프로젝트라는 의미입니다. 웹 페이지를 돌리기 위해서 웹서버가 필요한데 그것은 Servers 프로젝트가 담당합니다. jsp프로젝트에서 만들 수 있습니다. 로컬 PC에 설치된 Tomcat 같은 WAS를 이용하는 프로젝트입니다.

debug할 jsp 페이지를 하나 만들어보겠습니다.
jsp page

jsp page


JSP 파일은 debugjsp project 내에 WebContent라고 자동 생성된 디렉토리 아래 놓아둡니다. project명을 따라서 context가 정해지는데 일단 /debugjsp 라는 것이 URL에 따라다닌다는 정도만 기억하십시오. debug.jsp 파일을 만듭니다.
<%@ page language="java" contentType="text/html; charset=utf-8"
    pageEncoding="utf-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>debug jsp</title>
</head>
<body>
<%
    for (int i = 1; i <= 9; i++) {
        for (int j = 1; j <= 9; j++) {
            out.println(i + " * " + j + " = " + i * j);
            out.println("<br>");
        }
        out.println("<hr/>");
    }
%>
</body>
</html>

똑같은 알고리즘 3번째 보니까 토나올 것 같지 않나요? ㅎㅎ;
일단 샘플이 재밌어야 공부할 맛 나는데, 제가 나이가 많이 들었나 봅니다. ^^;
다음과 같은 화면이 보이겠죠.
debug.jsp

debug.jsp


소스도 다 되었겠다 이제 디버그 모드로 움직여 봅시다. 아 출발하기 전에 중단점 하나 찍어줘야죠. 브레이크댄스 아니, 브레이크포인트. JSP에서는 scriptlet부분에 중단점이 찍힙니다. HTML태그나 javascript 라인에는 중단점을 찍을 수 없습니다. 다 되는 거 없냐구요? 만드세요. ^^;
아주 방법이 없는 것은 아닙니다. JSP와 javascript의 실행환경이 다르다고 전에 말씀을 드린 적이 있습니다. 때문에 디버그 모드가 따로 분리되어야 됩니다. 서버쪽에서 일어나는 행동은 eclipse의 debug를 사용하고 브라우저쪽의 디버깅은 firebug를 사용하면 양쪽 모두 디버깅을 할 수 있습니다.

적당한 곳에 중단점을 찍으셨으면 보일겁니다. 괜히 bookmark 찍어놓고 "아 조타" 이러지 마세요. 디버깅하고 북마크하고는 찍은 것 빼고는 다르니까요. debug.jsp파일명에서 메뉴를 불러냅니다. 컨텍스트 메뉴 하단에 Debug As 라고 보일 것이고, 확장을 하면 Debug on Server 가 보입니다. 아래 그림을 보시면 소심하게 찍혀있는 중단점 보이시죠? ^^; 전 찍었습니다. 휘릭~! 아, 도망가면 안 되지 강좌는 끝내야죠. ㅎㅎ
debug jsp menu

debug jsp menu



디버그 퍼스펙티브로 볼 것이냐고 이클립스가 물어올 겁니다. 가야죠. 다음과 같이 보일 겁니다. java debug랑 똑같습니다. 다른 게 있다면 Variables쪽에 보이는 것이 엄청 많다는 것과 Tomcat WAS의 Thread가 적나라하게 보입니다.
debug jsp perspective

debug jsp perspective


이후 step over, step into, step return 등은 java와 동일합니다. 이로써 jsp까지의 디버깅 방법은 간략하게 알아보았습니다. 어설픈 설명 보시느라 수고 많으셨습니다.

좋은 하루 되세요.


참고: 빵세님의 Eclipse 3.2 WTP + resin 환경에서 jsp디버그
http://bangse.tistory.com/5
이클립스를 씁니다.
좋은 툴이 있는데, 콘솔에서 힘들게 디버깅하는 것은 내키지 않는 일입니다.
$JAVA_HOME/bin/jdb.exe 얘기하는 겁니다. 사실 잘 쓰기 힘듭니다. 아직 그런 상황은 겪지 않아서겠죠.

eclipse에서 Java프로젝트를 만들어서 다음과 같이 구구단을 만들어 보겠습니다.

소스2 Multiplication.java
package net.okjsp.study;

/**
 * An Application for Multiplication Table
 * @author heogwangnam
 */
public class Multiplication {

    /**
     * executable method
     * @param args
     */
    public static void main(String[] args) {

        for (int i = 1; i <= 9; i++) {
            for (int j = 1; j <= 9; j++) {
                System.out.println(i + " * " + j + " = " + i * j);
            }
            System.out.println("-----------------------");
        }

    }

}

구구단에 환장한 사람 같네요. 사용하는 예제마다 구구단이라니. ^^; 그래서 좀 색다르게 해봤습니다. 영어 좀 썼습니다. Multiplication Table. 계속 가죠. ^^;
이클립스에서는 이렇게 보입니다.

debug java

debug java


브레이크포인트를 찍어보겠습니다. for문이 시작되는 라인의 앞쪽 여백에 더블클릭을 하면 다음과 같이 점이 찍힙니다.
java breakpoint

java breakpoint

이제 디버그 모드로 들어가보겠습니다.
context menu Debug As

context menu Debug As

파일을 선택하고 컨텍스트 메뉴를 열면 Debug As 라는 메뉴가 보입니다. 거기에서 Java Application 을 선택합니다. 화면은 ㅎㅎ MacOS X입니다. Windows 도 마찬가지입니다. 아, 리눅스도요. 모두 이클립스 세상입니다. ㅎㅎ;
퍼스펙티브가 바뀐다고 창이 하나 뜨는데, 바꿔줍니다. 다음과 같이 화면 레이아웃이 바뀌면서 디버그 퍼스펙티브로 변경됩니다.

debug perspective

debug perspective


Debug 뷰 패널에 우측 상단에 보이는 아이콘들은 디버그 흐름을 컨트롤하는 기능들입니다. 지난 번 말씀드린 Step Into(F5), Step Over(F6), Step Return(F7) 기능과 좌측에 Resume을 확인할 수 있습니다. Drop to Frame이라는 새로운 메뉴도 보일텐데, 해당 메소드의 시작부터 다시 실행할 수 있는 기능입니다. 디버그를 종료하고 다시 시작하는 것이 아니라 현재 디버깅하는 메소드의 첫부분으로 다시 돌아가서 실행하는 기능입니다.

우측 Variables 뷰에는 변수들의 내용이 있습니다. 이클립스 디버깅에 관한 것은 차후에 더 알아보도록 하겠습니다.

다음 글은 JSP 디버깅입니다. 기대하십시오.

디버그(debug)는 쉽지 않은 작업입니다. 벌레 잡는 일이 프로그램에서 가장 정성이 많이 들어가는 작업이기도 합니다.
  1. 디버그의 기본
  2. 자바스크립트 디버그
  3. Java debugging
  4. JSP debugging
이 네 가지에 대해서 글을 써보려고 합니다.
디버그의 기원은 초기 계전기 사이에 있는 죽어있는 나방이 컴퓨터의 오작동을 일으켰고, 그 나방을 제거하자 정상 작동한 것에서 유래를 찾고 있습니다. 말 그대로 de+bug 입니다. ㅎㅎ

프로그래밍을 할 때 정상적인 데이터가 들어왔을 때를 기준으로 설계를 합니다. 하지만 프로그램을 실행할 때 발생하는 예상하지 못했던 경우로 인해 버그가 발생합니다. 숫자입력을 기대했는데, 문자가 들어오는 경우나 자료실을 운영하는데 서버의 하드디스크가 꽉 차는 경우를 예로 들 수 있습니다.

전자의 경우는 프로그램 수정을 통해서 디버그 하기 용이합니다. 후자의 경우는 하드디스크 공간 확장 내지는 불필요한 파일 삭제 등의 조치가 필요한데, 제가 설명하려는 영역에서 제외합니다.

프로그램을 디버깅하기 위해서는 버그를 발생시키는 코드와 그 때 사용된 테스트 값이 필요합니다. 버그를 재현할 수 있다면 프로그램의 약점을 파악한 것입니다. 따라서 디버깅이 쉽게 됩니다. 가장 어려운 경우는 간헐적으로 발생하는 버그입니다. 어떤 이유로 발생하는지 파악하기 어렵기 때문에 디버깅이 아주 어렵습니다. 범인 집 앞에 잠복해 있는 형사의 심정이라고 할까요.
디버깅을 의학에 비유한다면 내시경과 같습니다. 전신마취하지 않고 내시경 받아보셨나요. 아주 죽습니다. 디버깅도 프로그램을 한줄씩 살펴보는 작업이 동반되는데, 아주 고된 작업이 되기 쉽습니다.


debugging에서 알아야 할 용어들을 먼저 소개합니다.
  • breakpoint : 중단지점입니다. 실행 모드가 아닌 디버그 모드에서 프로그램을 중지하게 되는 지점의 표시입니다.
    보통 ide에서 소스 라인 맨 앞 여백을 더블클릭하면 생깁니다. 다시 더블클릭하면 없어집니다. resume을 실행하면 다음 중단점을 만날 때까지 실행됩니다.
  • step over : 한줄을 실행합니다. 함수가 있어도 실행 후 다음으로 넘어갑니다.
  • step into : 함수 내부로 들어갑니다.
  • step out : 함수를 끝까지 실행시키고 호출시킨 곳으로 되돌아 갑니다.
  • resume : 디버그로 한 줄 한 줄 실행시키는 트레이스 모드를 그만두고 실행모드로 전환합니다.

일단 기본적인 용어는 이상과 같습니다. 디버거의 종류에 따라 확장된 기능들이 있지만 기능이 소개될 때 같이 언급하겠습니다.
다음은 자바스크립트 디버깅을 설명하기 위한 소스입니다.

소스 : debug1.html (UTF-8)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>javascript debug</title>
<script type="text/javascript">
    // 전역변수 count
    var count = 0;
    /**
     * count값을 #place div에 출력하는 함수
     */
    function doPrint() {
        var place = document.getElementById("place");
        count++;
        place.innerHTML = count;
    }
</script>

</head>
<body>
<input type="button" value="trigger" onclick="doPrint()">
<div id="place"></div>
</body>
</html>

간단히 자바스크립트를 테스트할 수 있는 html과 javascript 코드입니다. input버튼을 클릭하면 doPrint() 자바스크립트 함수를 호출합니다.
디버깅을 위해서는 디버깅 도구가 필요합니다. firefox의 플러그인 firebug를 사용해보겠습니다.

소스1 debug1.html 파일을 만들고 firefox로 엽니다. 우측 하단의 firebug플러그인 활성화 영역을 클릭하여 그림1과 같이 firebug영역을 활성화합니다. 여러 개의 탭 중에서 Script 탭을 열면 HTML 소스와 함께 Script 소스들이 보입니다.

그림1 firebug script tab그림1 firebug script tab


디버깅은 쉽습니다. 그림2와 같이 JavaScript 함수의 내부인 14라인에서 앞쪽의 회색부분을 클릭하면 브레이크 포인트가 걸립니다. 디버그 준비 끝입니다.

그림2 JavaScript Debug Breakpoint그림2 JavaScript Debug Breakpoint

 
브라우저에서 버튼을 클릭하면 이 함수가 호출되는 소스인데 한 번 눌러보시면 화면에 브라우저 내의 객체들과 변수들이 그림3과 같이 firebug의 우측 패널에 나타납니다. 아울러 브레이크 포인트가 찍힌 곳에 화살표가 나타나면서 JavaScript의 실행이 중단 됩니다.

그림3 Debug start그림3 Debug start


id가 place인 element의 속성들을 확인할 수 있습니다. 여기서 디버깅을 계속하기 위해서 다음 아이콘들을 사용할 수 있습니다.

그림4 debug icons그림4 debug icons


하늘색 아이콘은 continue (F8) 입니다. resume 이라고 앞 서 설명드린 기능인데 다음 브레이크포인트를 만날 때까지 실행하게 됩니다. 만약 다음 브레이크포인트가 없다면 "기냥 고"가 되겠죠. ^^; 그 옆 아래로 향하는 아이콘은 Step Over (F10) 입니다. 한 줄 실행하고 대기하게 됩니다. 그 옆의 오른쪽으로 향하는 아이콘은 Step Into (F11), 라인에서 함수를 만나면 그 함수 안으로 비집고 들어가는 기능입니다. 그렇다면 나머지 한 개의 아이콘은 말 안해도 되죠? ㅎㅎ. 기냥 고?
삐질까봐 말씀드립니다. Step Out (F12) 인데 비집고 들어갔던 함수에 볼 게 없다면 나와야죠. 함수에서 밖으로 빠져나오게 됩니다.
흠... Step Over 를 실행해보죠. F10 키를 눌러도 됩니다. count 변수는 어디 숨었을까요? 함수 바깥에 있는 전역변수이기 때문에 this 안에 있습니다. 그림5를 참고하세요.

그림5 debug step over그림5 debug step over


to be continued...


+ Recent posts