Technical stuff Requirements are like water. They're easier to build on when they're frozen.

-> what is SW quality?
-> the BankAccount example
—> PHPUnit 3.4.12 is used for these examples
—> CLI run using phpunit BankAccountTest
—> phpunit –testdox BankAccountTest —> used for instance to present functionality summary before the actual coding
—> setUp()
—> Q&A —> use @expectedException annotation instead of the try/catch block inside the method body
—> Q&A —> use 1 test method for each test, not stuff everything in 1 method
—> PHPUnit 4 might use the traits feature of PHP, as opposed to the JUnit approach

-> organizing tests
—> tree structure, mirroring the actual code organization
—> using group annotation you can run only specific tests
—> phpunit –filter testFreezingAnObjectWorks Tests [ excludes a specific slow test ]

-> automated bugfixes project
—> write a test to repro the bug
—> use genetic programming to issue the patch that fixes the bug

-> SW testing pyramid /// Categories of (Unit) Tests
—> bottom level: unit tests
—> upper level: functional tests [this is not the functional testing w/ Selenium!] [it's testing blocks of functionality instead units] [do the interfaces between classes abide their contracts?]
—> top-level: End-to-End Test [these are the expensive ones ... running a full Selenium arrangement across all browsers took more than 24h]

-> minimalistic MVC implementation
—> used to demo unit testing for more than just the Model
—> assertAttributeEmpty() and assertAttributeContains() work with public / private / private class members
—> @depends is a simple way of declaring dependencies between tests
—> sample of refactoring so that there’s no need to assertAttribute*() for protected / private members

-> PHPUnit Best Practices
—> use an XML configuration file
—> look inside the cwd for a phpunit.xml [fallback to phpunit.xml.dist]
—> generate code coverage report, showing also dead code
—> new beta thingy: code coverage distribution report + class complexity