This document summarizes a lesson on server-side programming that covers functions, assertion testing, software testing, different types of testing, test-driven development, and pairing programming. It discusses functions, assertions, unit testing, integration testing, and test-driven development processes. It provides an example dojo assignment to write basic math functions using assertions and handling errors.
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
DIG1108 Lesson 7
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
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