← Back to team overview

mvhub-dev team mailing list archive

notes from class #2

 



##############

Desktop/91.350_class_02_notes.txt
                be able to define 'unit test'
                more familiar with unit test concepts
		      writing with test framework
  		      mocking
		      test harness
		      coverage
		
                know how to run our unit tests
cdw
mv_prove -r app-mvhub/t lib-mvhub/t

# on test at a time
lib-mvhub/t/$TEST_NAME.t

                know how to time our test code
mv_prove --timer

                know how to run profiler on our test code
mv_profile <file>
# see nps.$USER.testing123.net/dev/profile

		understand code review criteria
		      how do we decide to approve / disapprove

                do code review of code to speed tests
                more familiar with code review process / criteria

                identify slow tests
                identify tests that are good candidates for speed-up

######### Defined ###########
Wikipedia says Unit test is:

In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be
an individual function or procedure.
######### why ?  ##########
WHY TEST?

WHY NOT TEST ?
      slower code development now
      In the long run we are all dead

WHAT CANT BE DONE WITH UNIT TESTS ?
    usibibilty
    intigration
    meta

######### Unit test Concepts ###########
WRITING TESTS

#!/usr/bin/perl
use strict;
use warnings;

use Test::More tests=>1;
ok(1==1,'1 equals 1');
ok(1==2,'1 equals 2');
ok(0/0==0,'divide by zero is ok';
diag "a helpful error msg";

#################
COVERAGE
  mv_cover

      http://nsp.omacneil.testing123.net/dev/cover
######################
MOCKING
      database
      network
      non-testable interface

# replacing sub
  lib-mvhub/t/Utils/Setup/add_dns.t
# mocking object
  lib-mvhub/t/lib/MVHub/AgencyAccount/Test.pm

############## subtle testing benefits / test coverage benefits #########

  1) make testable interfaces which are better for other things
  2) make better code by reading it
  3) make better coder
      a. write more code
      b. feedback
###########
CODE REVIEW CRITERA
    better in some way
    worse in no ways
	not ugly
	    --local standards
		  Full::Module:Spec::to_func();
	    -perl best practices the book

    not giving desired result (bug)
    slow

"worse" ****DOESN"T**** mean missing feature
############
CODE REVIEW RESULTS
    comment
    needs fixing
    approve
    approve with suggestions

  --merge code

############ STRETCH #################
IDENTIFY SLOW TESTS

  mv_prove -r --timer app-mvhub/t lib-mvhub/t > timer.txt

  sort -rnk 5 test_times.txt > sorted.txt

  # remove cruft
  $EDITOR sorted.txt
#############
IDENTIFY CANDIDATES FOR SPEEDUP
  # mech tests are web server and speeding web sever

#############
IDENTIFY SLOW TEST PARTS

# always find keys last place you looked

    cdw
    mv_profile app-mvhub/t/perltidy.t

#############
Stretch Goal (time permitting)
                identify  tests to optimize.
		    open bugs
                submit non-trivial merge request --this
                may stretch over some sessions