dig1108 lesson 7

12
INTRO TO SERVER SIDE PROGRAMMING Week Seven Friday, October 18, 13

Upload: vc-dig1108-fall-2013

Post on 12-May-2015

379 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: DIG1108 Lesson 7

INTRO TO SERVER SIDE PROGRAMMINGWeek Seven

Friday, October 18, 13

Page 2: DIG1108 Lesson 7

Review - FunctionsFunctions 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 blockNothing 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

Page 3: DIG1108 Lesson 7

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 correctnessA 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 executeA postcondition - placed at the end - describes the expected state at the end of execution

Friday, October 18, 13

Page 4: DIG1108 Lesson 7

assert( 1 + 1 == 1 );// PHP Warning: Assertion failedassert( "1 + 1 == 1" );// PHP Warning: Assertion "1 + 1 == 1" failedassert_options( ASSERT_WARNING, false );if( ! assert( "1 + 1 == 1" ) )// No PHP Warning message

Friday, October 18, 13

Page 5: DIG1108 Lesson 7

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

Page 6: DIG1108 Lesson 7

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

Page 7: DIG1108 Lesson 7

Test-Driven DevelopmentTest-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 exist2. Run the tests to generate feedback and observe3. Write some code that attempts to provide the function4. Run the tests to generate feedback. Note failures and continue to write code to produce a success5. Repeat as necessary

Friday, October 18, 13

Page 8: DIG1108 Lesson 7

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

Page 9: DIG1108 Lesson 7

Rules of the Code DojoPair 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

Page 10: DIG1108 Lesson 7

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

Page 11: DIG1108 Lesson 7

Dojo AssignmentWrite 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

Page 12: DIG1108 Lesson 7

Dojo HomeworkCreate a new file in your assignments rep named assignment-8.1.md and open itResearch the different kinds of testing that we discussed, specifically Unit Testing and Integration Testing and cite some of the cons and pitfalls of themFind 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 classList at least three of the many active testing frameworks for PHP with links to the project pagesSave your work, commit changes and push to Github

Friday, October 18, 13