We started working with tests at the Flatiron School in week two. Every week tests have grown in complexity and we’ve encorporated new tools into our repetoir. We are now we’re now in our 6th week and I decided it was time to break it down and do a full inventory of tools. This more for my own benefit than the world at large, but maybe others will find it useful also.
What is testing?
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. (Thanks Wikipedia). Even more than this simple definition, we do (Test Driven Development (TDD))[http://ruby.about.com/od/advancedruby/a/tdd.htm], which means we write our tests before we write out code, then write code to pass the tests. This, of course, mean that tests are very important to development to sucess of writing quality software. First, lets zoom way out to get some larger context from the industry (Rubiests didn’t invent testing, of course.) We’ll then drill down into the specifics of how testing is used in Ruby and some of the most common tools.
Software Testing in General
At Flatiron we dove straight into working with tests without delving into much of the theory surrounding testing. For a bit of context, the industry will often refer to testing as White Box, Black Box, Gray Box or Visual Testing.
White Box Testing: White-box testing (also known as clear box testing, glass box testing, transparent box testing and structural testing) tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases.
Black Box Testing: A method of software testing that examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings.
Gray Box Testing: Is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects if any due to improper structure or improper usage of applications.
Levels of Testing
- Unit tests
- Feature / integration tests
- Visual testing
- Others…
Unit Testing: Tests basically just a Ruby class. *i.e., controller tests that use a fake htp request to test functionality.
Integration Testing (Feature Testing) *Starts up a real web server and runs through actual motions of the program. Actually completes the edits, etc. that are occuring on the site being tested. Typical techniques for this are either using stubs/drivers or execution from a debugger environment.
Top-down and Bottom-up Testing (at the Flatiron, we’ve also talked about this as Inside-out or Outside-in testing).
Tools Galore!
Rubiests love to test and holy buckets have they created every imaginable tool to make the process easier, more though, more susscint, more verbose and colloquial… You name. There is a probably a tool that will help you do it.
Considering the different levels of programming, these are a few tools that we have discussed so far or that I have stumbled upon on my own. This list is far from exhaustive.
Rspec
Rspec is what we learn here at the Flatiron School and the testing suite of choice for most ruby developers. It comes equipt with it’s own DSL or domain specific language for completing the task of writing tests for your code.
The basic components of an Rspec • The model’s create method, when passed valid attributes, should be valid. • Data that fail validations should not be valid. • Class and instance methods perform as expected.
It describes a set of expectations–in this case, what the Contact model should look like. • Each example (a line beginning with it) only expects one thing and starts with a verb.
Rspec expectations: Outlines the preferred format for Rspec tests as of the last version.
Capybara: for full acceptance tests Drivers, Headless browers (doesn’t require gui or javascript runtime)
Cucumber. “It’s a lie.” —Avi Flombaum Not possible for not technical people to be writing specs.
