5. Automated Testing Basics
What are unit tests?
A unit test is an automated piece of code that invokes a unit of work in the
system and then checks a single assumption about the behavior of that
unit of work. A unit of work is a single logical functional use case in the
system that can be invoked by some public interface (in most cases).
What is code coverage?
Code coverage is a measure used to describe the degree to
which the source code of a program is tested by a particular
test suite.
6. Testing Enhancers
• Fixtures
(Fixtures allow you to populate your testing database with predefined data before your tests run. )
• Factory Girl
(allow customization when you instantiate the objects and it aims to ensure that you
have a valid object to work with within your tests)
• Rspec
• Capybara
(Capybara helps you test web applications by simulating how a real user would interact with your
app.)
• Cucumber
• Database cleaner
(Database Cleaner is a set of strategies for cleaning your database
• in Ruby.)
7. Testing processes
TDD – Test Driven Development
1-write,run,fail test;
2-write minimal amount of code to pass test;
3-re-run test;
4-refactor code;
5-re-run test
Objectives
-Encourages simple design
-forces decoupled code
-creates robust test suite
-Focuses more on functionality
I.e. - Rspec
8. Testing processes
• BDD – Behavior Driven Development
generally arose from the idea that software development
should be managed by both the business and engineering.
So it seeks to create a common language between the two.
-”Given”, “When”,”[And]”,”Then”
Objectives
-Encourages collaboration
-Mimics user behavior
-delivers meaningful tests
I.e. - Cucumber
10. Benefits of Automated Testing
• Organizationally speaking it puts the burden of code
quality on the developers.
• Promotes code collaboration
• Eases resistance and/or fear of technical changes
• Promotes efficiency
• A form of documentation
• Shortens the feedback loop
• Frees up testing resources
11. Economics of Automated Testing
Technical debt - is a recent metaphor referring to the eventual consequences of poor
system design, software architecture or software development within a codebase. The
debt can be thought of as work that needs to be done before a particular job can be
considered complete or proper
12. Testing Models
• Agile Test Automation Pyramid
(http://www.velocitypartners.net/blog/2014/01/28/agile-testing-the-agile-test-automation-pyramid/)
• Agile Testing Quadrants
(http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/)
• Google’s: Small, Medium, Large
(http://googletesting.blogspot.com/2010/12/test-sizes.html)
15. Testing Models
• In the traditional view, most if not
all of the effort was in developing
UI-centric functional tests that
explored the application via the
GUI. There might be some lower-
level tests and a few unit tests, but
teams mostly staid at the upper
tier.
• The first change is taking a whole-
team view. Instead of the testers
being responsible for testing AND
writing all of the test automation,
it becomes a whole-team
responsibility. The developers take
most of the ownership for unit-
level automation, but testers can
operate here as well. The upper
tier focuses on limited UI-based
automation. Usually, these are
longer running, core customer
usage workflows that are best
implemented at this level.
16. Testing Models and efficiency
TESTING BY LAYERS
Most bang for your buck testing your model thoroughly
17. Testing Technics
Using design patterns to enhance your tests.
• Fat Model/Skinny Controller
-The idea of developing your code in such a way
that utilizes all the benefits of activeRecord in
your model rather than placing your logic in your
controller.
-Following this pattern lends itself to
better test scripts.
18. Controllers
• Controllers are pass-through entities
• Mostly boilerplate-biz logic belongs in the
model
• Controllers are “dumb” or “Skinny”
• They follow the “Controller Formula”
• Minimum Valid Object ( Factory Girl )
19. Controller/Reads Test Pattern
Make a request (with id of record if a single record)
Check rendering
correct template
redirect
status code
content type (html, json, xml,..)
Verify Variable Assignments
required by view
21. Controller Create/Update Test Pattern
• Make request with form fields to be
created/upd’d
• Verify Variable Assignments
• Verify/Check Success
– Variable is saved / record created
• Verify Failure/Error Case
• Rendering
• Variables are defined
• Record not saved
• Verify HTTP Verb protection
23. Model Testing
THINGS TEST SHOULD COVER
• Verify Validations
• Verify Custom functions
• Verify Associations
• Verify Nested Attributes
• Show example
24. Testing Views
• Emphasize behavior over display
• Check that the application handles errors
correctly
• Test views for things that could go wrong
badly
25. Testing Technics
Page Object Pattern
Within your web app's UI there are areas that your tests interact with. A Page Object simply
models these as objects within the test code. This reduces the amount of duplicated code and
means that if the UI changes, the fix need only be applied in one place.
Normal SDLC Agile processes with not agile infrastructure.
Had to hand hold user stories through to production, explaining how to test at every environment
Wanted to give this presentation to deepen my understanding of writing more efficient, relevant, maintainable scripts
Speaking from a outsider’s/new comers perspective, crash course I wish I had beyond the basic rspec how-to’s
First thing I had to understand is that I shouldn’t try to cover all the bases with my scripts. There are many types of testing all of which aren’t best to be covered in an automated fashion.
the testers were the ones primarily writing the automation, so their comfort zone was towards functional testing. It didn’t help that the majority of the automated testing tools were focused towards leveraging the functional UI as the point of entry. Ie tools like selenium.
ut this strategy is flawed. It’s inherently unstable and brittle; as the application (UI) changes the automation is nearly always impacted. Therefore one problem is automation stability and ongoing maintenance costs.
