We care about writing quality code, we have read the definition of SOLID principles several times and we know how important they are for writing good OO code, but are we really following those principles? Is there a pragmatic way of following them in our day to day jobs or are they just some principles a few computer scientists wrote? Fortunately there is, SOLID principles are not just good ideas , they are intended to help us write better code, enjoy our jobs more and be happy programmers. But, where should we start? We should start where we always do. By writing tests, yes, for real. As Kent Beck says "TDD doesn't drive good design. TDD gives you immediate feedback about what is likely to be bad design", so we need to go a step further. In this talk we will see how writing tests is not just *doing TDD* is about having good test coverage, it's also about driving our code towards good design, one that follows SOLID principles.
Spies are a relatively new feature in RSpec. In this tutorial-style talk: we'll look at what spies are, how spies work in RSpec and how one can write better tests with spies. We'll work through some of examples of writing new tests with spies, improving old tests with spies and the reasons why spying is a useful tool for your testing practice.
If you're new to RSpec and looking for ways to improve your testing practice, understand the library better or just ask some questions, this session will be great for you.
“A testing tool by any other other name would assert as truthy.” – some guy. You’ve seen Rails’ built-in Test::Unit in the morning session. This afternoon, we’ll introduce RSpec, another popular testing tool. We’ll overview basic structure, contexts, “should” expectations, mocking and stubbing. We’ll also cover Rails model, view, controller, routing, helper, and request specs.
Everybody wants to do test-driven development, but switching to TDD or BDD on an existing project that doesn't have tests presents special challenges. Often, the current code is a tangled mess of dependencies that defeats the very concept of unit testing. Worse, if somebody has attempted TDD in the past, you might have a test suite that needs to be fixed before any new tests can be written.
Don't give up. Adding test-coverage and TDD to your application will make it easier.
This session will describe techniques that you can use to bootstrap a test-driven process into your project. You'll see how to use "black-box" techniques that don't depend on the structure of the code and "white-box" techniques that interact with the code more directly.
Topics covered will include:
* Using Cucumber to perform black-box testing.
* Using RSpec to perform white-box testing
You’ve heard the claims or know from experience that test-driven development (TDD) produces better code. Perhaps you’ve also heard that to write better code you should be following the SOLID principles. Is there a connection between practicing TDD and writing SOLID code?
In this talk, I’ll use examples gleaned from real life to demonstrate how TDD prompts us to produce code that conforms to the SOLID principles, and how the SOLID principles are where we should turn when our tests are causing us pain. In doing so, we’ll learn what each principle really means and why it’s valuable.
Mike Nicholaides has been a Rails consultant since 2006 and has always obsessed about writing clean, clear, and concise code. He organizes the Code Retreat in Philadelphia where the focus is on learning TDD, communicating with code, and of course, having fun.
Is your test suite comprehensible to someone new to the project? Can you find where you tested that last feature? Do you have to wade through dozens of files to deal with updated code?
Organizing tests are hard. It is easy to make things overly elaborate and complicated. Learn an approach to grouping the tests together in a way that makes sense. We can test drive without creating overly brittle tests. Lets build better designed projects by keeping our test suite clear and understandable.
Regression testing is invaluable to knowing if changes to code have broken the software. However, it always seems to be the case that no matter how many tests you have in your regression buckets, bugs continue to happily creep in undetected. As a result, you are not sure if you can trust your tests anymore or your methodology, and you are ready to change that. I will present a powerful technique called mutation testing that will help make your tests capable of detecting future bugs. I will also give you a metric to assess the effectiveness of your tests in terms of regression, so that future changes in your software can be done with impunity.
Audience will learn:
What mutation testing is and why it works.
When and how to apply mutation testing.
How to improve their tests so they detect bugs that are introduced during the normal evolution of software.