metricfu/metric_fu charliesome/better_errors Sucking less at writing Cucumber — Rendered Text I wrote my first Cucumber scenario about five months ago. It went something like this: Scenario: Changing email Given I am logged in And I am on the homepage When I click on "Account" And I fill in "email" with "milos@example.com" And I press "Change Email" Then I should see "Email successfully changed" When I visit "My profile page" Then I should see "milos@example.com" Maybe my naivete was not solely to blame; I was told it was so easy “that it could be taught to a secretary”. Some of the problems with the above scenario are: It’s too long and verbose It’s not using the domain language Read the scenario. Background: Given I am logged in Scenario: Changing Email Given I am on my account page When I change my email Then I should see that my email has changed Using web steps makes you write very imperative scenarios that you have to rewrite each time you change something. We still test if this whole system works but if I change how it works I only need to change the step definitions.
Summer Breeze: creates dynamic Rails fixtures for Jasmine tests On stage at Red Dirt Ruby Conference, Noel Rappin has released Summer Breeze, a gem that makes working with Jasmine in Rails a bit easier. Summer Breeze dynamically creates Rails fixtures for your Jasmine tests. Installation and usage To install via RubyGems: gem install summer_breeze … and run the bundled generator: rails generate summer_breeze:install Now you can define you fixtures in the generated initializer: fixture "PostsController##index.body_container" You then have several options for telling Jasmine about your new fixture: sb.loadFixture(fixture_name) sb.findSelector(fixture_name, selector) sb.readFixture(fixture_name) A sample test might look like: it("hides text when asked", function() { $form_container = sb.findSelector('login', '.form_container'); toggle_handlers.init(); $hide_link = $form_container.find(".toggle_link"); expect($hide_link).not.toHaveClass("hidden"); $hide_link.click(); expect($hide_link).toHaveClass("hidden"); }); [Source on GitHub]
noelrappin/summer_breeze With Proper TDD, You Get That First thing's first - I need a UI. How else can you play, without a UI? It's the most important thing in the game, right? Couple of minutes and I have some basic HTML and CSS in place; it renders a 3x3 grid, not the sexiest thing in the world, but it'll do. So what's next? First few moves are pretty easy. Hmmm, I'm already at 4 hours - I guess I wasn't really halfway done when I was 30 minutes into it. Several days later Yes! Guess what. So now I have go back to my "nextMove" function and try to figure out where it goes wrong. I wonder if my friends are still willing to sacrifice more of their time to play the game again several times. A better solution By now it should be obvious that this approach to software development is a good way to lose your hair, your client, and your computer out the window. First thing - your friends should not be your regression and acceptance tests. With proper TDD, you get that. Second thing - you should never be scared to change code. The Ad
Agile Development of Frontend Javascript using AngularJS, Jasmine, Testacular & Jenkins | Agile India 2014 Conference Submission System I love being around awesome people, who build great products customers desire. I love learning from and together with these amazing minds. I love creating the right environment for teams to flourish. I love change, and learning from new experiences. I love working in Agile environments. How about you? The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change. In our everyday life doing Agile we already respect these aspects in many ways. I'd like to challenge your current way of thinking about people and processes. In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And why not take it even further? Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.
Comparing googlemock to Mocha Higher-level languages are great, but every now and then I like some good old C++. So I was a bit excited when I got the chance to use C++ recently on a piece of demo software. After spending a lot of time in Ruby and Javascript (or more accurately, Coffeescript), it was both comforting and frustrating to be back in the land of pointers, memory allocation, and static types. Since this code was meant for a demo, it was originally written to be throw-away. looks something like this in C++ with googlemock: It’s certainly not as elegant as Ruby, but given that it’s C++, I’d call that quite readable and practical. In the course of writing the tests, I naturally found myself restructuring code to make it more modular, to make it have better separation of concerns. Here is another example: Mocha: Googlemock: One thing that really impressed me about googlemock was how it easy it is to make arbitrary parameter matchers. you can use _ to match any parameter.
Not Tending to "The Build" – A Common Anti-Pattern The Build is an essential cog of any software project, but it is most often maintained by identified “experts.” This needs to stop. Agile depends on shared code ownership and understanding of the system — all parts of the system. Consequences of Ignoring the Build Most sufficiently-sized projects use a continuous integration system and some amount of configuration and/or code to make them work. If only a subset of individuals understands and maintains this system, it will likely not be kept up to snuff to meet the growing demands of the project. I have experienced the effects of an insufficiently-maintained build system on numerous projects in the past. Continuous integration systems, which use The Build, are invaluable for regression testing. Where Things Go Wrong The most disheartening aspect of this problem is that The Build is indeed code, just like the real code that developers write every day. Does your team tend to the build environment over the course of a project?
Test Driven Development: Resistance Is... Perplexing? Recently I’ve been working with a mixed team of developers – contractors from a few companies with varied backgrounds. Our manager is sold on the value of test-driven development (TDD), but most of the team is anything but. The typical reaction to discussion of TDD is highly emotional and highly negative. This resistance is unexpected and perplexing to those of us who use TDD regularly – why wouldn’t you want to leverage a tool that improves your code quality and design, allows you to safely refactor throughout the course of your project, and gives you confidence to make changes late in your development cycle? At Atomic Object, test-driven development is not optional and its value is not a matter of debate. We’ve seen what it brings to projects over and over, and it’s all too easy for us to spot the quality difference in code bases developed without tests. Confidence in Code Quality You’ve probably worked on a project with no test suite or an untrusted test suite. Ability to Refactor
A Beginning Developer's Experience With TDD As a summer intern at Atomic Object, I’ve learned a lot about Test-Driven Development (TDD), a practice that Atomic uses heavily. I’d used TDD in one college class, but it wasn’t really explained; we just sort of used it without knowing exactly what was going on. On my current project, we’ve been using TDD a lot, and learning the process has been difficult. Why TDD? TDD helps me understand what my code is doing. One of the things that I noticed about myself before working at Atomic was that I wasn’t always sure what my code was doing. When I write a test, I have a clear indication of how I want my application to behave. TDD requires me to learn new testing frameworks. In order to TDD an application, you will need to learn some new testing frameworks for the language you are writing in. Prior to using TDD, I used a lot more trial and error and print debugging. TDD helps me to learn new languages faster. Since starting TDD, I have learned more about not only Rails, but Ruby as well.
Getting Started With Konacha: JavaScript Testing on Rails Konacha is a testing tool for JavaScript applications running on Rails. Why Konacha? It’s very fast.It treats JavaScript like a first-class citizen: Your tests are written in JavaScript, call into JavaScript code, and inspect JavaScript objects. You can still trigger events, e.g. with jQuery, if you need to simulate user actions.It comes with support for the Rails asset pipeline. [1]It supports CoffeeScript.You can use the in-browser runner (good for development), or run your test suite from the command line through Selenium (good for build servers). What it cannot do is talk to the server. It cannot use the database.It cannot access your Rails (server-side) views. When you need either of these two, write integration tests with Capybara instead. Tutorial: Overview Testing Plain JavaScript Let’s start by testing some pure JavaScript (without DOM manipulation). To test this, first add Konacha to your Gemfile: Now mkdir -p spec/javascripts, and create a spec file: Testing the DOM Writing Tests