Testing. You should do it. (and other wise sayings) Jon McCartie September 2011

No content

“Don't touch anything that doesn't have [test]coverage. Otherwise, you're not refactoring; you're just changing $#!^.” Hamlet D'Arcy

Why Testing? Avoid the “click around” test Deferring bug fixes to users Cost of finding/fixing bugs now vs. later Only write the code that NEEDS to be written Bug fixes - write a failing test first • • • • •

Technical Debt We don’t have time to clean-up that function -- we’ll get to it later We need to get this feature out NOW -- let’s fix that in the next release #TODO Not sending local changes to be merged upstream • • • • “If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets.” Steve McConnell

Why Testing? Requirements Architecture Construction System Test Post-release Requirements Requirements Architecture Architecture Construction Construction System Test System Test Post-release Post-release 0 20 40 60 0 0 20 20 40 40 60 60 Phase of Development Phase of Development Cost (times) Cost (times) Cost to Fix a Defect Steve McConnell, Code Complete

Test-Driven Development (TDD)

No content

Test Driven Development (TDD) Writing tests now is easier than later Over time, you’ll forget what it the function did Writing tests first leads to more-easily testable code Tests can be used as specifications Immediate feedback -- “Am I done yet?” • • • • •

Test Driven Development (TDD) What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer. http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

Test Driven Development REFACTOR GREEN RED 1. Write a test that fails 2. Make the code work 3. Eliminate redundancy

Test Driven Development Write simplest and smallest amount of code to make the test pass -- prevents over-engineering. Make SURE you get red before you write code. False positives = BAD! • •

TDD - Tools Ruby: Rspec, Test::Unit, Minitest Python: unittest PHP: PHPunit Java: JUnit COBOL: ? • • • • •

Approaches to Testing White Box / Black Box Testing Unit Testing: verify the functionality of a specific section of code Integration Testing: verify the interaction between integrated components • • •

Testing for the Web: Starter Pack Model / Controller / View Model / Controller Model / Integration • • •

Models Test everything that could break One test for each of your validations One test for every method in your model • • •

Models it "does not save a post without title" do post = Post.new post.save.should be_false end The Test The Implementation class Post < ActiveRecord::Base validates_presence_of :title end

Controllers Was the web request successful? Was the user redirected to the right page? Was the user successfully authenticated? Was the correct object stored in the response template? Was the appropriate message displayed to the user in the view? • • • • •

Controllers it "is successful" do get :index response.should be_success assigns(:posts).should_not be_nil end The Test The Implementation def index @posts = Post.all end

Views Testing the response to your request by asserting the presence of key HTML elements and their content is a useful way to test the views of your application. •

Views assert_select 'ul.navigation' do assert_select 'li.menu_item' end The Test The Implementation

Miskelaneaous Routes Mailers Helpers • • •

Fake It Don't test against your development environment -- test against a clean test environment Fixtures Factories Stubs Mocks • • • • •

Integration Tests Integration tests are used to test the interaction among any number of controllers. They are generally used to test important work flows within your application. • •

Integration Tests test "login and browse site" do https! get "/login" assert_response :success post "/login", :username => users(:avs).username, :password => users(:avs).password assert_equal '/welcome', path assert_equal 'Welcome avs!', flash[:notice] https!(false) get "/posts/all" assert_response :success assert assigns(:products) end

Acceptance Tests aka “Functional Tests” Black-box tests Automated • • •

No content

Behavior Driven Development BDD extends TDD by writing easily-readable tests that stakeholders can read/write. • "BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters." Dan North aka: Test what the user/stakeholder sees and how they interact with the application. •

Behavior Driven Development Gherkin syntax

Behavior Driven Development 1) Describe behavior in plain text

Behavior Driven Development 2) Write a step definition

Behavior Driven Development 3) Run and watch it fail

Behavior Driven Development 4) Write code to make the step pass

Behavior Driven Development 5) Run again and see the step pass

Behavior Driven Development 6) Repeat 2-5 until green like a cuke

Behavior Driven Development Example Rails feature

BDD - Tools Ruby: Cucumber Python: PySpec PHP: Behat Visual Basic: (ohrly?) • • • •

No content

Questions?