Your SlideShare is downloading. ×
DIG1108 Lesson 7
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

DIG1108 Lesson 7

374
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
374
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. INTRO TO SERVER SIDE PROGRAMMING Week Seven Friday, October 18, 13
  • 2. 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
  • 3. 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
  • 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 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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