In-class notes for 01/19/2018 (CS 284 (MCA), Interim 2018)

In-class notes for 01/19/2018

CS 284 (MCA), Interim 2018

~cs284/.bin/dopsql ? (for HW4)
More in-class query exercises?
Log form, timely logs. Log at least 30 hours/week on your project from today through Monday 1/29
Project repos

Submitted questions on assignments and technology

Lab 10

Progress? Part 1 due this afternoon at 1pm
(Testing on the command-line.) Test-driven development does not require a framework!

Develop a practice of finding convenient some way to test every change in your code.
Example (for Lab 10 development):
- On server machine (such as rns202-3.cs.stolaf.edu):
```
java Backend 284xx > & Backend.out.new ; diff Backend.out.new Backend.out
```
  Here is an explanation.
  - The text file Backend.out.new contains the output from this run of Backend, and Backend.out contains the output from a previous successful run.
    - Just before the first time you run Backend, enter
```
touch Backend.out
```
      This will give the diff command something to compare to.
    - Just after your first successful run of the first stage of Backend, and any other time you want to update Backend.out, enter
```
cp Backend.out.new Backend.out
```
- The & character causes standard output and standard error to merge (on the default csh in the Link)
- Having both commands (java ... and diff ...) on the same line makes it easy to use uparrow to rerun the test
On client machine:
```
java Sender rns202-3.cs.stolaf.edu 284xx < Sender.in > & Sender.out.new ; diff Sender.out.new Sender.out
```
Here is an explanation.
- The text file Sender.in contains your test input line(s).
- The text file Sender.out.new contains the output from this run of Sender, and Sender.out contains the output from a previous successful run.
  - See notes above for Backend.out for suggestions on managing Sender.out
Demo
(Multi-threaded program output). For a multi-threaded program (such as later versions of Lab 10's Backend), different correct runs of that program may produce differing output.
- For example, suppose multiple Sender programs are interacting with a multithreaded Backend server that includes a separate Thread object for communicating with each Sender. Assume that each Sender transmits messages "line 1" and "line 2", and assume that the Backend prints those messages together with a thread ID number, e.g.,
```
Thread 1 received "..."
```
  Then both
```
Thread 1 received "line 1"
Thread 1 received "line 2"
Thread 2 received "line 1"
Thread 2 received "line 2"
```
  and
```
Thread 1 received "line 1"
Thread 2 received "line 1"
Thread 2 received "line 2"
Thread 1 received "line 2"
```
  represent correct output, because the differences only depend on ordering of executions among the threads.
In this case, a simple diff of output will show differences between these two correct runs, but those ordering differences aren't significant.

In this kind of situation, one strategy is to compare sorted output from the program. Here's an example command-line test.
```
java Backend 284xx > & Backend.out.new ; sort Backend.out.new | diff - Backend.out
```
The highlights indicate key changes in comparison to the original testing command-line.
- Note that this approach retains the unsorted Backend.out.new in case its useful for debugging
After debugging, when it's time to record a new Backend.out, enter
```
sort Backend.out.new > Backend.out
```
instead of using cp.
Note: The command-line strategy above doesn't generally constitute TDD (Test-Driven Development) unless you change the expected output files Sender.out and Backend.out before each code addition, adding extra development output lines as needed to measure whether that code addition can generate the desired results.

However, that strategy does constitute TDD for refactoring, when the goal of changes is to produce identical operation (measured by the output) with a better design. This suggests a useful semi-TDD development strategy:
1. Refactor code as needed to prepare for an added feature, so that the feature addition will be a relatively simple change in the modified version. (This is the TDD part.)
2. Make the new code addition, and check that the changes in output are correct.
3. Record the changed output in Backend.out
4. Repeat
The convenience of the command-line tests makes this development strategy feasible.

< >