1. ENEE150 – 0102 ANDREW GOFFIN Testing and Debugging

2. Testing Your Code With projects, we will provide public test vectors  These are simple text files that can be redirected through stdin  If your output matches the test’s output, you’ve passed the test! Can redirect input/output with the ‘>’ and ‘<‘ characters ./a.out test.out  This uses test.in as input and redirects the output to test.out Goffin – ENEE150

3. Testing Your Code Use ‘diff’ to see if your output and test output are the same  diff test.out correct_test.out > diff.txt  Redirects all differences between the outputs into a file called ‘diff.txt’  If diff.txt is empty, you’ve passed! Goffin – ENEE150

4. Debugging Your Code The debugger for C in Unix systems is GDB  Command line based  Typical GDB commands:  next (n) – go to next line in current function  step (s) – go to next line that runs (goes into subroutines)  run (r) – run the program  break - stop program at line/function  print (p) - prints the value of a variable  To run GDB on a program, compile the program with the ‘-g’ flag  gcc –g Goffin – ENEE150

5. Debugging Your Code Running GDB  gdb a.out will start the debugger Goffin – ENEE150

6. Debugging your Code GDB tips and tricks  Use the –tui flag to see the code as you step through  Always set a break point before running, otherwise it’ll just run the code as normal  Try to pinpoint where an error may be in your code and set the breakpoint at that line/function Goffin – ENEE150

7. Project 1 Questions? Some tips:  You’re reading the input as (x,y), however the chess array is indexed using the y coordinate (row) first!  Use the_board_color[y][x], not the_board_color[x][y]  Test modularly  Test each function individually… the public tests are made for this to be easy  Make sure your output matches that of the tests!!!  You WILL lose points if the outputs are different Goffin – ENEE150