INTRO TO SERVER SIDE PROGRAMMING
Week Seven

Friday, October 18, 13
Review - Functions
Functions must start with the function keyword, must
contain a valid function identifier (with variables), provide an
optional list of arguments surrounded by parentheses, even
if there are none, and a block of code:
function do_something( $an_argument, $another ) {
// Code goes here
}
Nothing from outside is visible to code in the block
Nothing inside the block is visible outside the function
Pass values into a function as arguments at invocation:
do_something( 'some value', "$another_value );
Friday, October 18, 13
Assertion Testing
An assertion is a predicate (true-false statement) placed
in a program to indicate that the developer thinks that
the predicate is always true at that place.
Programmers can use assertions to help specify
programs and to reason about program correctness
A precondition- an assertion placed at the beginning of a
section of code, determines the set of states under which
the programmer expects the code to execute
A postcondition - placed at the end - describes the
expected state at the end of execution

Friday, October 18, 13
assert( 1 + 1 == 1 );
// PHP Warning: Assertion failed
assert( "1 + 1 == 1" );
// PHP Warning: Assertion "1 + 1 == 1" failed
assert_options( ASSERT_WARNING, false );
if( ! assert( "1 + 1 == 1" ) )
// No PHP Warning message

Friday, October 18, 13
Software Testing
Software testing is the process of validating and verifying
that the software:
meets requirements that guided its design and development
works as expected (produces the desired outputs/behavior)
satisfies the needs of stakeholders

Automated testing is the process of writing software that
performs automated, repeatable isolated tests on a
completely separate software system called the System
Under Test (SUT)

Friday, October 18, 13
Types of Testing
Assertion testing - is this statement correct? Can it be incorrect?
Unit testing - does this function produce the expected output?
Functional testing - does this module provide the expected
functionality?
Integration testing - do these modules work together?
System testing - can we run this software where we need it?
Validation testing - does it do what we said that it was supposed to do?
Acceptance testing - is it actually useful to the intended users?
Regression testing - now that we fixed something what else did we
break?

Friday, October 18, 13
Test-Driven Development
Test-driven development is a software development process
that relies on the repetition of a very short development cycle.
The developer writes an automated test case that defines a
desired improvement or function, then produces the minimum
amount of code to pass that test and finally refactors the new
code to acceptable standards
1. Write code that describes a function that would be desirable
to have but does not yet exist
2. Run the tests to generate feedback and observe
3. Write some code that attempts to provide the function
4. Run the tests to generate feedback. Note failures and
continue to write code to produce a success
5. Repeat as necessary

Friday, October 18, 13
How Does Testing Help?
Writing and running an automated, repeatable and isolated test suite
against your software answers:
How do I know that my system provides the desired functionality
according to the provided specs?
When a bug surfaces, how do I know where in the codebase the
problem exists and whether or not I've fixed it?
When I add a new functionality or correct a bug, how do I know that I
haven't broken something else?
How can I ensure that a bug, once fixed, does not resurface when I fix
another bug or add more functionality?
If I improve the structure or organization of my code for readability,
how do I know that it still works the same way?

Friday, October 18, 13
Rules of the Code Dojo
Pair Programming:
Pilot-Copilot
One person is the pilot and does the typing
One person is the copilot and tries to talk the solution out
Everyone else is passengers (quiet while flying!)

Timed for X minutes, then:
The pilot becomes a passenger, the copilot becomes the pilot, a
passenger becomes the new copilot

Repeat until the problem is solved, everyone has been pilot and
copilot, or we run out of time

Friday, October 18, 13
Rules of the Dojo cont.
Test Driven Development:
Red-Green-Refactor
Red: the pilot cannot write any production code until there is at
least one failing test
Green: the pilot should only write production code that attempts
to satisfy the current failing tests, save and rerun frequently
Refactor: Once all tests are passing, look for opportunities to
simplify or improve readability before moving on

Don't talk while Red:
Only the pair can talk while the timer is running
Allow the pair time to figure out the next steps on their own

Friday, October 18, 13
Dojo Assignment
Write a set of functions that all accept exactly two
parameters and provide the functionality of a basic
calculator: addition, subtraction, multiplication and
division. Use simple assertion tests to develop in a test
driven manner:
assert( 'add(1,1) == 2' );
assert( 'sub(4,2) == 2' );
Ensure that your test covers positive and negative
numbers for all operations and multiplication or division
by zero. The program should never produce a Fatal Error,
so handle error conditions internally

Friday, October 18, 13
Dojo Homework
Create a new file in your assignments rep named
assignment-8.1.md and open it
Research the different kinds of testing that we discussed,
specifically Unit Testing and Integration Testing and cite
some of the cons and pitfalls of them
Find a link to at least one blog post or article in favor of
testing and one against and save them to your file,
preparing to discuss them in class
List at least three of the many active testing frameworks
for PHP with links to the project pages
Save your work, commit changes and push to Github
Friday, October 18, 13

DIG1108 Lesson 7

  • 1.
    INTRO TO SERVERSIDE PROGRAMMING Week Seven Friday, October 18, 13
  • 2.
    Review - Functions Functionsmust start with the function keyword, must contain a valid function identifier (with variables), provide an optional list of arguments surrounded by parentheses, even if there are none, and a block of code: function do_something( $an_argument, $another ) { // Code goes here } Nothing from outside is visible to code in the block Nothing inside the block is visible outside the function Pass values into a function as arguments at invocation: do_something( 'some value', "$another_value ); Friday, October 18, 13
  • 3.
    Assertion Testing An assertionis a predicate (true-false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. Programmers can use assertions to help specify programs and to reason about program correctness A precondition- an assertion placed at the beginning of a section of code, determines the set of states under which the programmer expects the code to execute A postcondition - placed at the end - describes the expected state at the end of execution Friday, October 18, 13
  • 4.
    assert( 1 +1 == 1 ); // PHP Warning: Assertion failed assert( "1 + 1 == 1" ); // PHP Warning: Assertion "1 + 1 == 1" failed assert_options( ASSERT_WARNING, false ); if( ! assert( "1 + 1 == 1" ) ) // No PHP Warning message Friday, October 18, 13
  • 5.
    Software Testing Software testingis the process of validating and verifying that the software: meets requirements that guided its design and development works as expected (produces the desired outputs/behavior) satisfies the needs of stakeholders Automated testing is the process of writing software that performs automated, repeatable isolated tests on a completely separate software system called the System Under Test (SUT) Friday, October 18, 13
  • 6.
    Types of Testing Assertiontesting - is this statement correct? Can it be incorrect? Unit testing - does this function produce the expected output? Functional testing - does this module provide the expected functionality? Integration testing - do these modules work together? System testing - can we run this software where we need it? Validation testing - does it do what we said that it was supposed to do? Acceptance testing - is it actually useful to the intended users? Regression testing - now that we fixed something what else did we break? Friday, October 18, 13
  • 7.
    Test-Driven Development Test-driven developmentis a software development process that relies on the repetition of a very short development cycle. The developer writes an automated test case that defines a desired improvement or function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards 1. Write code that describes a function that would be desirable to have but does not yet exist 2. Run the tests to generate feedback and observe 3. Write some code that attempts to provide the function 4. Run the tests to generate feedback. Note failures and continue to write code to produce a success 5. Repeat as necessary Friday, October 18, 13
  • 8.
    How Does TestingHelp? Writing and running an automated, repeatable and isolated test suite against your software answers: How do I know that my system provides the desired functionality according to the provided specs? When a bug surfaces, how do I know where in the codebase the problem exists and whether or not I've fixed it? When I add a new functionality or correct a bug, how do I know that I haven't broken something else? How can I ensure that a bug, once fixed, does not resurface when I fix another bug or add more functionality? If I improve the structure or organization of my code for readability, how do I know that it still works the same way? Friday, October 18, 13
  • 9.
    Rules of theCode Dojo Pair Programming: Pilot-Copilot One person is the pilot and does the typing One person is the copilot and tries to talk the solution out Everyone else is passengers (quiet while flying!) Timed for X minutes, then: The pilot becomes a passenger, the copilot becomes the pilot, a passenger becomes the new copilot Repeat until the problem is solved, everyone has been pilot and copilot, or we run out of time Friday, October 18, 13
  • 10.
    Rules of theDojo cont. Test Driven Development: Red-Green-Refactor Red: the pilot cannot write any production code until there is at least one failing test Green: the pilot should only write production code that attempts to satisfy the current failing tests, save and rerun frequently Refactor: Once all tests are passing, look for opportunities to simplify or improve readability before moving on Don't talk while Red: Only the pair can talk while the timer is running Allow the pair time to figure out the next steps on their own Friday, October 18, 13
  • 11.
    Dojo Assignment Write aset of functions that all accept exactly two parameters and provide the functionality of a basic calculator: addition, subtraction, multiplication and division. Use simple assertion tests to develop in a test driven manner: assert( 'add(1,1) == 2' ); assert( 'sub(4,2) == 2' ); Ensure that your test covers positive and negative numbers for all operations and multiplication or division by zero. The program should never produce a Fatal Error, so handle error conditions internally Friday, October 18, 13
  • 12.
    Dojo Homework Create anew file in your assignments rep named assignment-8.1.md and open it Research the different kinds of testing that we discussed, specifically Unit Testing and Integration Testing and cite some of the cons and pitfalls of them Find a link to at least one blog post or article in favor of testing and one against and save them to your file, preparing to discuss them in class List at least three of the many active testing frameworks for PHP with links to the project pages Save your work, commit changes and push to Github Friday, October 18, 13