Software testing during the transition to Agile, particularly if you’re moving from a classic waterfall system, is not easy. This part discusses how to perform software testing when you don’t have the classical workflow of documented test cases and bug requests than in a traditional approach.
Tests are supposed to save us money. How is it, then, that many times they become millstones around our necks, gradually morphing into fragile, breakable things that raise the cost of change? We write too many tests and we test the wrong kinds of things.
This article from Alan Bowers and James Bell provides an introduction to setting up a software testing infrastructure using Selenium WebDriver and Cucumber. It shows how to create a test suite for single-page web applications and to run tests across multiple web and mobile browsers via Selenium Grid.
Software testing is a good thing, right? But how much should we test? What’s not enough? What’s too much? What should we test, and when? This talk looks at the many levels of testing, from the outermost UI tests to unit tests, what works well, what doesn’t work well.
Testing during the transition to Agile, particularly if you’re moving from a classic waterfall system, often means throwing out every expectation you have about how a project will be run, how long you’ll have to prep or test a drop, and when new code will arrive.
Slow tests got you down? As Ruby developers, you might watch a lot of tests run in a given day. So why not make it more fun? This talk takes a light-hearted approach to introducing you to an array of test reporters including MiniTest’s Pride, Fuubar, and Nyan Cat Formatter. In addition, it shows how easy it is to make your very own test reporter for both Rspec or Minitest so you can have a more enjoyable testing experience.