Project Overview
This project will be quite different from our
previous projects. Rather than writing production code, you will instead be
writing tests in one part and using the debugger in the other. The project is
smaller than P4 and our deadline reflects that. There are two main portions:
Problem 1: Testing
The first part of the project focuses on
developing the ability to write test cases for an existing class.
In the project pack, a directory called testme contains multiple
implementations of a simple system to calculate various salary-related things.
One of these implementations is correct, while the remaining ones all contain
bugs. You will write test cases based on the provided class documentation to
discern which implementation is correct. The correct implementation should pass
all tests while the buggy versions should all fail at least one test, likely
many more. You will earn credit for each wrong implementation that fails tests
(when the correct one is still passing tests!), and for correctly identifying
the correct version.
Importantly, you do not have access to
the source code for any of the implementations. Instead, you must rely
on the documentation of the intended purpose of the classes to develop your
tests.
Each implementation is in its own package and
subdirectory. Later sections describe how to run your single testing file
against any particular implementation without copying files around. (hint:
opening and closing files repeatedly in DrJava is not a good
workflow).
Problem 2: Debugging
The second part of the project involves
developing your skills to trace code and utilize the debugger to follow
execution.
The debugme directory of the project pack
contains DebugMe.java, a sneaky program which requires a lot of
command line arguments to be passed into it to run to completion. The first
argument will always be your GMU netID (e.g. gmason76) which will uniquely
use the arguments for you in ways different from other students.
DebugMe.java is divided into a
series of phases with each requiring different command line input to complete.
Your task is to use the debugger, reverse-engineer what is
Project Overview
This project will be quite different from our
previous projects. Rather than writing production code, you will instead be
writing tests in one part and using the debugger in the other. The project is
smaller than P4 and our deadline reflects that. There are two main portions:
Problem 1: Testing
The first part of the project focuses on
developing the ability to write test cases for an existing class.
In the project pack, a directory called testme contains multiple
implementations of a simple system to calculate various salary-related things.
One of these implementations is correct, while the remaining ones all contain
bugs. You will write test cases based on the provided class documentation to
discern which implementation is correct. The correct implementation should pass
all tests while the buggy versions should all fail at least one test, likely
many more. You will earn credit for each wrong implementation that fails tests
(when the correct one is still passing tests!), and for correctly identifying
the correct version.
Importantly, you do not have access to
the source code for any of the implementations. Instead, you must rely
on the documentation of the intended purpose of the classes to develop your
tests.
Each implementation is in its own package and
subdirectory. Later sections describe how to run your single testing file
against any particular implementation without copying files around. (hint:
opening and closing files repeatedly in DrJava is not a good
workflow).
Problem 2: Debugging
The second part of the project involves
developing your skills to trace code and utilize the debugger to follow
execution.
The debugme directory of the project pack
contains DebugMe.java, a sneaky program which requires a lot of
command line arguments to be passed into it to run to completion. The first
argument will always be your GMU netID (e.g. gmason76) which will uniquely
use the arguments for you in ways different from other students.
DebugMe.java is divided into a
series of phases with each requiring different command line input to complete.
Your task is to use the debugger, reverse-engineer what is happening in each
phase-method, and determine what command-line arguments are necessary in order
to satisfy the phase. When missing or improper inputs are detected in a phase,
the program throws exceptions and escapes back to attempt the next phase. You
will earn points for each phase that you successfully "defuse".
Project Files
p5pack/
|
+--ANSWERS.txt : Describe written answers to problems in this file
|
+--debugme/
| |
| +--DebugMe.java
|
+--testme/
|
+--docs/ (javadoc output for an implementation)
| |
| +--index.html
| +--...
|
+--PayrollTest.java (write more tests here)
|
+--junit-4.12.jar
|
+--imp1/
| |
| +--payroll
| |
| +--Dict.class
| |
| +--Payroll.class
|
+--imp2/
| |
| +--payroll
| |
| +--Dict.class
| |
| +--Payroll.class
|
+--remaining impN/ directories: same structure as imp1/ and imp2/ above
|
...
Problem 1: Test Mode Activated
The first task is to add many
@Test-annotated methods to PayrollTest.javaand determine which of the many
implementations are bad, and which one is good. Then describe your results
in ANSWERS.txt.
The code we're testing out tries to calculate various salary-related
things based on employees and their (yearly) salaries. The implementor got a
bit carried away and made a very generic
Dict<K,V> class to track the (key,value)
pairings representing (employee-name, yearly-salary), as part of the
calculation.
We linked the
Javadoc documentation
to this part of the project at the top of this specification. A copy is also
included in p5pack/testme/docs. You could locally open up the p5pack/testme/docs/index.html file without being online.
We're only supplying the
.class files for each implementation; you don't get to look for the
bugs directly, you have to just think about what the purpose of the code is,
and then write test cases based on that purpose. (You're writing "black
box" test cases).Running Your Tests
Note that running one test file against many implementations can
be tedious if we're not smart about it. A typical (but bad) novice approach is
to make many copies of the file which will quickly get out of sync as changes
are made to one and the copies are not updated.
Instead, utilize the ability of the compiler and runtime of java
to set a class path on the command line to cause a search for
classes in the specified locations. Navigate to the
testme/ directory and run commands like the
following which runs tests on implementation 1 only:demo$ javac -cp .:imp1/:junit-4.12.jar *.java
demo$ java -cp .:imp1/:junit-4.12.jar PayrollTest
These commands tell Java that it should first compile all
.java files it finds when looking in the current directory
(.), in the imp1/ directory, and it should also look through the junit-4.12.jar file while compiling; then, it again
needs access to code in all three of those locations, but it should run
the mainmethod of PayrollTest.
If you want to run tests on a different implementation, just
change the
imp1 to a different directory, as indemo$ javac -cp .:imp2/:junit-4.12.jar *.java
demo$ java -cp .:imp2/:junit-4.12.jar PayrollTest
For this task, the command line is likely superior to most IDEs.
For instance, these commands will not work in DrJava. It's likely that most
IDEs will struggle with this task. Take this as an opportunity to beef up your
command line skills. It offers the ultimate flexibility and the only price to
unlock that is a little practice (on the order of cut-pasting some ready-made
commands).
Scripts to run tests
To ease the task of testing on the command line, two scripts are
provided which will compile and run all implementations.
On Unix/Mac OS X use the
unix-compile-test.sh script in a terminal.> cd testme
> unix-compile-test.sh
Results of testing all implementations are summarized by only
showing how many tests failed (or that it was OK!). If you need to understand
why a particualr implementation is behaving some way, then don't use the script
here, use the just-one-implementation commands shown above!
On Windows use the
windows-compile-test.cmd script in the cmd.exeterminal.> cd testme
> windows-compile-test.cmd
Results will be left in the
results.txt text file due to the lack of a
good grepon the Windows
platform.Goals for the Testing Problem
Multiple implementations of the
payroll package are provided. One of these
is correct while the remainder are crap. It is known that implementations imp2, imp8,
and imp11 are broken.
To complete this project, do the following:
- Create enough tests that all implementations but one are failing at least one test.
- Write
tests for both the
DictandPayrollclasses. Problems may exist in one, the other, or both. - Document your test cases to indicate what they are testing. Part of your grade will be assigned based on the documentation of test cases.
- Submit
your
PayrollTest.javafile which we will run against all implementations. - Identify
the general flaws in the
behavior of each of the known broken implementations. Describe these flaws
in a few sentences in the provided
ANSWERS.txtfile which will be submitted with your code.
(40%) Grading Criteria for the Testing Problem GRADING
- 10%
: Identify the correct implementation and report it in
ANSWERS.txt. This implementation must pass all of your test cases to get the full 10% credit here. Narrowing to limited candidates gets partial credit. (e.g., if you're not sure which of 2-3 remaining implementations is the correct one, but it is still in those remaining ones, you'll get a bit of credit). - 12%
: Each faulty implementation fails at least one test in your
P5Tests(1% per implementation). Points might not be earned if all implementations (including the correct one) fail at least one test! That would mean you have bogus tests that definitely aren't correct, themselves. - 9%
:
PayrollTestdocuments the intent of each test case using clear comments. - 9%
(3% each) : Flaws in the known broken implementations are adequately
described in
ANSWERS.txt.
Demo of Dict
The
Dict class provides a quite simple
dictionary implementation. Below is a demonstration of creating one and calling
some of its methods.> import payroll.*;
> Dict<String,Integer> d = new Dict<String,Integer>();
> d.put("one",1);
> d
{(one:1)}
> d.size()
1
> d.put("two",2);
> d.put("three",3);
> d.size()
3
> d.get("one")
1
> d.get("350")
java.util.NoSuchElementException: "350" key not in dict.
at payroll.Dict.complainNoKey(Dict.java:147)
at payroll.Dict.get(Dict.java:70)
> d.pop("two")
2
> d.toString()
"{(one:1),(three:3)}"
> d.keys()
[one, three]
> d.clear()
> d
{}
>
Demo of Payroll
The
Payroll class uses the Dict class in its implementation of some salary-related
calculations. Below is a demonstration of some basic uses of Payroll.> import payroll.*;
> Payroll p = new Payroll()
> p.hire("A",120);
> p.hire("A",120)
> p.hire("B",240)
> p.employees()
[A, B]
> p.topSalary()
240
> p.hire("C",1500)
> p.topSalary()
1500
> p.fire("C")
true
> p.employees()
[A, B]
> p.fire("C")
false
> p.giveRaise("A",0.5)
> p.getSalary("A")
180
> p.giveRaise(1.0) // everyone gets 100% raise!
> p.getSalary("A")
360
> p.getSalary("B")
480
> p.monthlyExpense() // for one month of twelve.
70
>
Problem 2: DebugMe!
A Programming Puzzle
The file
debugme/DebugMe.java is provided in the code pack and contains a puzzle.
The main() method in this program accepts a
series of command line arguments that, when correctly specified, will cause the
program to run to completion. If the command line arguments are not specified
correctly, the program will fail prematurely. The purpose of this problem is to
determine the correct inputs to cause the program to run to completion.DebugMe is
arranged in "stages" and passing stages earns points. After each run
the program prints the points earned based on the stages "passed".
Example:> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
Double debugger burger, order up!
oops! Game Over... >:(
* Score: 0/55 pts *
Notice that the first argument is always your NetID.
Don't use
msnyde14unless you are Prof. Snyder. DebugMe uses your NetID to create a unique set of conditions which
you must pass so that your experience with the program will likely be different
from other students.
This task is actually kinder to you - if you fail one phase, you
are able to continue to the next.
The stages in
DebugMe are
intentionally obscure. This is code that is meant to be a puzzle rather than
easily readable and to that end, you are strongly encouraged to use a
debugger while analyzing the program. Debuggers allow you to stop
execution at any point and examine variables, step forward line by line, and
ultimately identify which kinds of command line arguments will make it through
a stage and which will cause the dreaded failure()method to be invoked ending the run. A primary goal of this
problem is to gain experience with debuggers as they are incredibly useful tool
for a programmer to have in their utility belt. Credit for the problem is
entirely based on how many stages are passed.Command Line Arguments
The only artifact of your efforts will be the specific
command-line invocation of the program, as your only inputs are given as
command-line arguments.
- the
first command-line argument must be your GMU netID, e.g.
gmason76. Many of the phases will use this to randomize and personalize the code for you - you've got your very own unique project! - each phase (method) will read the next few arguments (however many it needs), and use them in more and more quirky ways.
- towards
the end of each phase, there will be some check and a guarded call
to
failure(). Your goal is to figure out what command-line arguments will cause these failures to never happen. - if you need to include spaces in a single argument, please use double-quotes.
Running DebugMe through
the Debugger
How can we use the debugger with command-line arguments? It's
surprisingly easy in DrJava:
- Compile
DebugMe.java - Set a breakpoint in the phase you're working on
- Turn on debugging mode under the debugging menu
- In
the Interactions Pane, run a command like this to launch
DebugMewith command line arguments.
> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
oops! Game Over... >:(
error msg: Failure! Double debugger burger, order up!
* Score: 0/55 pts.
If you've turned on debugging, though, you get to step through and
see what's happening.
- Most IDEs have a means of running a program through a debugger. Learn about your tool if you are not using DrJava.
- For
the brave, there is also a command line debugger, command
jdbwhich should be installed with every JDK. This is somewhat less convenient as it provides only limited source code display but can work with some classic unix tools.
Regardless of how you access the debugger, you will want to
familiarize yourself with features such setting breakpoints to stop the running
program, stepping forward line by line, and displaying the values of variables.
DebugMe is
not a "real" program as it is intentionally obscure. However, as an
exercise to learn how to analyze running programs it will provide invaluable
experience. Happy bug squashing.(60%) Grading Criteria for Problem 2: Debugging GRADING
- 55%
: In
ANSWERS.txt, report your command line after passing as many phases as possible. Paste the entire thing in, includingjava yourNetID. To complete all phases, a total of 29 command line args includingNetIDare required. - 5%
: In
ANSWERS.txtdescribe your experience using the debugger. What helped, what frustrated, and what lessons will you take forward? Limit your description to one to two paragraphs.
Make sure to answer the required questions
in ANSWERS.txt. This file is provided as part of the project
pack. It is also printed below.
PROBLEM
1: TESTING
==================
(10%)
The correct implementation is: (fill in your answer below)
imp
#:
--------------------------------------------------------------------------------
KNOWN
FAULTY IMPLEMENTATIONS (2, 8, 11)
----------------------------
(3%)
Describe the general problems with imp2
(3%)
Describe the general problems with imp8
(3%)
Describe the general problems with imp11
--------------------------------------------------------------------------------
PROBLEM
2: DEBUGGING
====================
--------------------------------------------------------------------------------
(55%)
Include the command line you found to pass as many phases as
possible.
Include your NetID at the beginning. To
complete all
phases,
a total of 29 command line args including NetID are required.
java
DebugMe netID
--------------------------------------------------------------------------------
(5%)
Describe your experience using the debugger. What helped, what
frustrated,
and what lessons will you take forward? Limit your
description
to one to two paragraphs please.
-------------------------------------------------------------------------
+--docs/ (javadoc output for an implementation)
| |
| +--index.html
| +--...
|
+--PayrollTest.java (write more tests here)
|
+--junit-4.12.jar
|
+--imp1/
| |
| +--payroll
| |
| +--Dict.class
| |
| +--Payroll.class
|
+--imp2/
Project Overview
This project will be quite different from our
previous projects. Rather than writing production code, you will instead be
writing tests in one part and using the debugger in the other. The project is
smaller than P4 and our deadline reflects that. There are two main portions:
Problem 1: Testing
The first part of the project focuses on
developing the ability to write test cases for an existing class.
In the project pack, a directory called testme contains multiple
implementations of a simple system to calculate various salary-related things.
One of these implementations is correct, while the remaining ones all contain
bugs. You will write test cases based on the provided class documentation to
discern which implementation is correct. The correct implementation should pass
all tests while the buggy versions should all fail at least one test, likely
many more. You will earn credit for each wrong implementation that fails tests
(when the correct one is still passing tests!), and for correctly identifying
the correct version.
Importantly, you do not have access to
the source code for any of the implementations. Instead, you must rely
on the documentation of the intended purpose of the classes to develop your
tests.
Each implementation is in its own package and
subdirectory. Later sections describe how to run your single testing file
against any particular implementation without copying files around. (hint:
opening and closing files repeatedly in DrJava is not a good
workflow).
Problem 2: Debugging
The second part of the project involves
developing your skills to trace code and utilize the debugger to follow
execution.
The debugme directory of the project pack
contains DebugMe.java, a sneaky program which requires a lot of
command line arguments to be passed into it to run to completion. The first
argument will always be your GMU netID (e.g. gmason76) which will uniquely
use the arguments for you in ways different from other students.
DebugMe.java is divided into a
series of phases with each requiring different command line input to complete.
Your task is to use the debugger, reverse-engineer what is happening in each
phase-method, and determine what command-line arguments are necessary in order
to satisfy the phase. When missing or improper inputs are detected in a phase,
the program throws exceptions and escapes back to attempt the next phase. You
will earn points for each phase that you successfully "defuse".
Project Files
p5pack/
|
+--ANSWERS.txt : Describe written answers to problems in this file
|
+--debugme/
| |
| +--DebugMe.java
|
+--testme/
|
+--docs/ (javadoc output for an implementation)
| |
| +--index.html
| +--...
|
+--PayrollTest.java (write more tests here)
|
+--junit-4.12.jar
|
+--imp1/
| |
| +--payroll
| |
| +--Dict.class
| |
| +--Payroll.class
|
+--imp2/
| |
| +--payroll
| |
| +--Dict.class
| |
| +--Payroll.class
|
+--remaining impN/ directories: same structure as imp1/ and imp2/ above
|
...
Problem 1: Test Mode Activated
The first task is to add many
@Test-annotated methods to PayrollTest.javaand determine which of the many
implementations are bad, and which one is good. Then describe your results
in ANSWERS.txt.
The code we're testing out tries to calculate various salary-related
things based on employees and their (yearly) salaries. The implementor got a
bit carried away and made a very generic
Dict<K,V> class to track the (key,value)
pairings representing (employee-name, yearly-salary), as part of the
calculation.
We linked the
Javadoc documentation
to this part of the project at the top of this specification. A copy is also
included in p5pack/testme/docs. You could locally open up the p5pack/testme/docs/index.html file without being online.
We're only supplying the
.class files for each implementation; you don't get to look for the
bugs directly, you have to just think about what the purpose of the code is,
and then write test cases based on that purpose. (You're writing "black
box" test cases).Running Your Tests
Note that running one test file against many implementations can
be tedious if we're not smart about it. A typical (but bad) novice approach is
to make many copies of the file which will quickly get out of sync as changes
are made to one and the copies are not updated.
Instead, utilize the ability of the compiler and runtime of java
to set a class path on the command line to cause a search for
classes in the specified locations. Navigate to the
testme/ directory and run commands like the
following which runs tests on implementation 1 only:demo$ javac -cp .:imp1/:junit-4.12.jar *.java
demo$ java -cp .:imp1/:junit-4.12.jar PayrollTest
These commands tell Java that it should first compile all
.java files it finds when looking in the current directory
(.), in the imp1/ directory, and it should also look through the junit-4.12.jar file while compiling; then, it again
needs access to code in all three of those locations, but it should run
the mainmethod of PayrollTest.
If you want to run tests on a different implementation, just
change the
imp1 to a different directory, as indemo$ javac -cp .:imp2/:junit-4.12.jar *.java
demo$ java -cp .:imp2/:junit-4.12.jar PayrollTest
For this task, the command line is likely superior to most IDEs.
For instance, these commands will not work in DrJava. It's likely that most
IDEs will struggle with this task. Take this as an opportunity to beef up your
command line skills. It offers the ultimate flexibility and the only price to
unlock that is a little practice (on the order of cut-pasting some ready-made
commands).
Scripts to run tests
To ease the task of testing on the command line, two scripts are
provided which will compile and run all implementations.
On Unix/Mac OS X use the
unix-compile-test.sh script in a terminal.> cd testme
> unix-compile-test.sh
Results of testing all implementations are summarized by only
showing how many tests failed (or that it was OK!). If you need to understand
why a particualr implementation is behaving some way, then don't use the script
here, use the just-one-implementation commands shown above!
On Windows use the
windows-compile-test.cmd script in the cmd.exeterminal.> cd testme
> windows-compile-test.cmd
Results will be left in the
results.txt text file due to the lack of a
good grepon the Windows
platform.Goals for the Testing Problem
Multiple implementations of the
payroll package are provided. One of these
is correct while the remainder are crap. It is known that implementations imp2, imp8,
and imp11 are broken.
To complete this project, do the following:
- Create enough tests that all implementations but one are failing at least one test.
- Write
tests for both the
DictandPayrollclasses. Problems may exist in one, the other, or both. - Document your test cases to indicate what they are testing. Part of your grade will be assigned based on the documentation of test cases.
- Submit
your
PayrollTest.javafile which we will run against all implementations. - Identify
the general flaws in the
behavior of each of the known broken implementations. Describe these flaws
in a few sentences in the provided
ANSWERS.txtfile which will be submitted with your code.
(40%) Grading Criteria for the Testing Problem GRADING
- 10%
: Identify the correct implementation and report it in
ANSWERS.txt. This implementation must pass all of your test cases to get the full 10% credit here. Narrowing to limited candidates gets partial credit. (e.g., if you're not sure which of 2-3 remaining implementations is the correct one, but it is still in those remaining ones, you'll get a bit of credit). - 12%
: Each faulty implementation fails at least one test in your
P5Tests(1% per implementation). Points might not be earned if all implementations (including the correct one) fail at least one test! That would mean you have bogus tests that definitely aren't correct, themselves. - 9%
:
PayrollTestdocuments the intent of each test case using clear comments. - 9%
(3% each) : Flaws in the known broken implementations are adequately
described in
ANSWERS.txt.
Demo of Dict
The
Dict class provides a quite simple
dictionary implementation. Below is a demonstration of creating one and calling
some of its methods.> import payroll.*;
> Dict<String,Integer> d = new Dict<String,Integer>();
> d.put("one",1);
> d
{(one:1)}
> d.size()
1
> d.put("two",2);
> d.put("three",3);
> d.size()
3
> d.get("one")
1
> d.get("350")
java.util.NoSuchElementException: "350" key not in dict.
at payroll.Dict.complainNoKey(Dict.java:147)
at payroll.Dict.get(Dict.java:70)
> d.pop("two")
2
> d.toString()
"{(one:1),(three:3)}"
> d.keys()
[one, three]
> d.clear()
> d
{}
>
Demo of Payroll
The
Payroll class uses the Dict class in its implementation of some salary-related
calculations. Below is a demonstration of some basic uses of Payroll.> import payroll.*;
> Payroll p = new Payroll()
> p.hire("A",120);
> p.hire("A",120)
> p.hire("B",240)
> p.employees()
[A, B]
> p.topSalary()
240
> p.hire("C",1500)
> p.topSalary()
1500
> p.fire("C")
true
> p.employees()
[A, B]
> p.fire("C")
false
> p.giveRaise("A",0.5)
> p.getSalary("A")
180
> p.giveRaise(1.0) // everyone gets 100% raise!
> p.getSalary("A")
360
> p.getSalary("B")
480
> p.monthlyExpense() // for one month of twelve.
70
>
Problem 2: DebugMe!
A Programming Puzzle
The file
debugme/DebugMe.java is provided in the code pack and contains a puzzle.
The main() method in this program accepts a
series of command line arguments that, when correctly specified, will cause the
program to run to completion. If the command line arguments are not specified
correctly, the program will fail prematurely. The purpose of this problem is to
determine the correct inputs to cause the program to run to completion.DebugMe is
arranged in "stages" and passing stages earns points. After each run
the program prints the points earned based on the stages "passed".
Example:> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
Double debugger burger, order up!
oops! Game Over... >:(
* Score: 0/55 pts *
Notice that the first argument is always your NetID.
Don't use
msnyde14unless you are Prof. Snyder. DebugMe uses your NetID to create a unique set of conditions which
you must pass so that your experience with the program will likely be different
from other students.
This task is actually kinder to you - if you fail one phase, you
are able to continue to the next.
The stages in
DebugMe are
intentionally obscure. This is code that is meant to be a puzzle rather than
easily readable and to that end, you are strongly encouraged to use a
debugger while analyzing the program. Debuggers allow you to stop
execution at any point and examine variables, step forward line by line, and
ultimately identify which kinds of command line arguments will make it through
a stage and which will cause the dreaded failure()method to be invoked ending the run. A primary goal of this
problem is to gain experience with debuggers as they are incredibly useful tool
for a programmer to have in their utility belt. Credit for the problem is
entirely based on how many stages are passed.Command Line Arguments
The only artifact of your efforts will be the specific
command-line invocation of the program, as your only inputs are given as
command-line arguments.
- the
first command-line argument must be your GMU netID, e.g.
gmason76. Many of the phases will use this to randomize and personalize the code for you - you've got your very own unique project! - each phase (method) will read the next few arguments (however many it needs), and use them in more and more quirky ways.
- towards
the end of each phase, there will be some check and a guarded call
to
failure(). Your goal is to figure out what command-line arguments will cause these failures to never happen. - if you need to include spaces in a single argument, please use double-quotes.
Running DebugMe through
the Debugger
How can we use the debugger with command-line arguments? It's
surprisingly easy in DrJava:
- Compile
DebugMe.java - Set a breakpoint in the phase you're working on
- Turn on debugging mode under the debugging menu
- In
the Interactions Pane, run a command like this to launch
DebugMewith command line arguments.
> java DebugMe msnyde14 0 0 0
Let the games... BEGIN!
Phase One, let's have some fun!
oops! Game Over... >:(
error msg: Failure! Double debugger burger, order up!
* Score: 0/55 pts.
If you've turned on debugging, though, you get to step through and
see what's happening.
- Most IDEs have a means of running a program through a debugger. Learn about your tool if you are not using DrJava.
- For
the brave, there is also a command line debugger, command
jdbwhich should be installed with every JDK. This is somewhat less convenient as it provides only limited source code display but can work with some classic unix tools.
Regardless of how you access the debugger, you will want to
familiarize yourself with features such setting breakpoints to stop the running
program, stepping forward line by line, and displaying the values of variables.
DebugMe is
not a "real" program as it is intentionally obscure. However, as an
exercise to learn how to analyze running programs it will provide invaluable
experience. Happy bug squashing.(60%) Grading Criteria for Problem 2: Debugging GRADING
- 55%
: In
ANSWERS.txt, report your command line after passing as many phases as possible. Paste the entire thing in, includingjava yourNetID. To complete all phases, a total of 29 command line args includingNetIDare required. - 5%
: In
ANSWERS.txtdescribe your experience using the debugger. What helped, what frustrated, and what lessons will you take forward? Limit your description to one to two paragraphs.
Make sure to answer the required questions
in ANSWERS.txt. This file is provided as part of the project
pack. It is also printed below.
PROBLEM
1: TESTING
==================
(10%)
The correct implementation is: (fill in your answer below)
imp
#:
--------------------------------------------------------------------------------
KNOWN
FAULTY IMPLEMENTATIONS (2, 8, 11)
----------------------------
(3%)
Describe the general problems with imp2
(3%)
Describe the general problems with imp8
(3%)
Describe the general problems with imp11
--------------------------------------------------------------------------------
PROBLEM
2: DEBUGGING
====================
--------------------------------------------------------------------------------
(55%)
Include the command line you found to pass as many phases as
possible.
Include your NetID at the beginning. To
complete all
phases,
a total of 29 command line args including NetID are required.
java
DebugMe netID
--------------------------------------------------------------------------------
(5%)
Describe your experience using the debugger. What helped, what
frustrated,
and what lessons will you take forward? Limit your
description
to one to two paragraphs please.
-------------------------------------------------------------------------
No comments:
Post a Comment