make results_test.py work better within python unittest framework

make results_test.py work better within python unittest framework

BUG=

Committed: http://code.google.com/p/skia/source/detail?r=12882

[epoger, 2014-01-02 21:24:08]

Ready for review at patchset 1.

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
File gm/rebaseline_server/results_test.py (left):

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:89: if not os.path.isdir(OUTPUT_DIR):
Moving all the pre- and post-test steps into setUp() and tearDown() allows us to
launch this unittest automatically in the standard Python unittest way:

epoger@wpgntat-ubiq141:~/src/skia/red/skia$ python -m unittest discover
--start-directory=gm/rebaseline_server --pattern='*_test.py' --verbose
test_gm (results_test.ResultsTest)
Process results of a GM run with the Results object. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.833s

OK

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/tests/o...
File
gm/rebaseline_server/tests/outputs/expected/results_test.ResultsTest.test_gm/gm.json
(right):

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/tests/o...
gm/rebaseline_server/tests/outputs/expected/results_test.ResultsTest.test_gm/gm.json:2:
"categories": {
This file moved into a new directory hierarchy.

[rmistry, 2014-01-03 15:18:42]

LGTM

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
File gm/rebaseline_server/results_test.py (right):

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:54: assert (not different_files), \
I find it slightly strange to see an assert in tearDown, but maybe that is ok.

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:75: 
Nit: Add one more newline here.

[epoger, 2014-01-03 15:42:07]

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
File gm/rebaseline_server/results_test.py (right):

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:54: assert (not different_files), \
On 2014/01/03 15:18:42, rmistry wrote:
> I find it slightly strange to see an assert in tearDown, but maybe that is ok.

Good point.  Added a comment explaining the situation.  Maybe we'll come up with
a better way.

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:75: 
On 2014/01/03 15:18:42, rmistry wrote:
> Nit: Add one more newline here.

Done.

[rmistry, 2014-01-03 15:44:17]

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
File gm/rebaseline_server/results_test.py (right):

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:54: assert (not different_files), \
On 2014/01/03 15:42:07, epoger wrote:
> On 2014/01/03 15:18:42, rmistry wrote:
> > I find it slightly strange to see an assert in tearDown, but maybe that is
ok.
> 
> Good point.  Added a comment explaining the situation.  Maybe we'll come up
with
> a better way.

Also another minor reason to not have it here: if somebody later comes along and
adds cleanup code below the assert then if tests fail the artifacts will not be
cleaned up.
This is not major, we can come up with a better solution later.

[epoger, 2014-01-03 15:48:08]

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
File gm/rebaseline_server/results_test.py (right):

https://codereview.chromium.org/122443006/diff/1/gm/rebaseline_server/results...
gm/rebaseline_server/results_test.py:54: assert (not different_files), \
On 2014/01/03 15:44:18, rmistry wrote:
> On 2014/01/03 15:42:07, epoger wrote:
> > On 2014/01/03 15:18:42, rmistry wrote:
> > > I find it slightly strange to see an assert in tearDown, but maybe that is
> ok.
> > 
> > Good point.  Added a comment explaining the situation.  Maybe we'll come up
> with
> > a better way.
> 
> Also another minor reason to not have it here: if somebody later comes along
and
> adds cleanup code below the assert then if tests fail the artifacts will not
be
> cleaned up.

Good point again.  Added that to my explanatory comment.

[commit-bot: I haz the power, 2014-01-03 15:48:41]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/epoger@google.com/122443006/180001

[commit-bot: I haz the power, 2014-01-03 16:04:21]

Change committed as 12882