Most teams run BDD scenarios as integration tests through the UI or API. It seems logical: Gherkin describes high-level behavior, so run high-level tests.
But what if that assumption costs you 10 minutes or even hours of feedback time, brittle infrastructure, and constant debugging?
I propose an approach that flips the script: BDD at unit level.
| { | |
| "LABEL": { | |
| "name": "PR title needs jira ticket", | |
| "color": "CC00CC" | |
| }, | |
| "CHECKS": { | |
| "alwaysPassCI": false, | |
| "prefixes": [ "Bump " ], | |
| "regexp": "\\[[A-Z]{2,}-\\d+(,\\s*[A-Z]{2,}-\\d+)*\\]", | |
| "regexpFlags": "", |
| var expect = require("chai").expect; | |
| var walk_tests = require("./walk_xunit_tests.js").walk_tests; | |
| var util = require('util'); | |
| describe("walk_tests", function() { | |
| let input = `<?xml version="1.0" encoding="UTF-8"?> | |
| <testsuites> | |
| <testsuite name="SuiteA" errors="0" skipped="1" tests="3" failures="1"> | |
| <testcase classname="Class A" name="test1" time="0.006" status="run"/> |
| require 'git' | |
| require 'json' | |
| filename = 'data.json' | |
| working_dir = 'resources/repo1/' | |
| g = Git.open(working_dir) #, :log => Logger.new(STDOUT)) | |
| history = [] | |
| g.log.path(filename).each do |log_entry| |
| INFO global: Vagrant version: 1.7.2 | |
| INFO global: Ruby version: 2.0.0 | |
| INFO global: RubyGems version: 2.0.14 | |
| INFO global: VAGRANT_DEFAULT_PROVIDER="virtualbox" | |
| INFO global: VAGRANT_EXECUTABLE="/opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/bin/vagrant" | |
| INFO global: VAGRANT_LOG="debug" | |
| INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/opt/vagrant/bin/../embedded" | |
| INFO global: VAGRANT_INSTALLER_VERSION="2" | |
| INFO global: VAGRANT_DETECTED_OS="Darwin" | |
| INFO global: VAGRANT_INSTALLER_ENV="1" |
| Applying Ideas From Conferences for Organizational Change | |
| Fanny Pittack and Alex Schwartz gave a presentation about insights from happy change agents at the Agile Testing Day Netherlands 2015. They talked about the challenges that people can have when they learn an idea at a conference and try to apply it in their work environment, and practiced a a change dojo with the attendants and provided suggestions to do successful change in organizations. | |
| Schwartz told his story about a change that he did to getting rid of a tool. At a conference he learned to avoid tools that are only used by one tester. Back at work he tried to convince the QA team to get rid of a specific tool, but the people that he was working with were not happy about that. In the end the tool was removed, so the change goal was achieved. But the relationship between him and his colleagues was damaged, making future cooperation and doing change more difficult. | |
| You have to focus on identifying the problem, understanding it well, and agree on it |
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" | |
| "http://www.w3.org/TR/html4/strict.dtd"> | |
| <html lang="en"> | |
| <head> | |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | |
| <title>Generic AWS Regional Status Page</title> | |
| <meta name="description" content="Generic AWS Regional Status Page"> | |
| <meta name="copyright" content="Copyright (c) 2012 Alex Schwartz"> | |
| <meta name="author" content="Alex Schwartz"> |
| require "socket" | |
| # The irc class, which talks to the server and holds the main event loop | |
| class IRC | |
| def initialize(params) | |
| @host = params[:host] | |
| @port = params[:port] | |
| @nick = params[:nick] | |
| @channel = params[:channel] |
| require 'sinatra' | |
| require 'open-uri' | |
| get '/?' do | |
| erb :index | |
| end | |
| get '/proxy/:domain/:port/?*' do |domain,port,path| | |
| puts "TBD: proxy domain #{domain}, path #{path}" |
| require 'rspec' | |
| describe 'AnagramPairFinder' do | |
| let(:dictionary) { %w{ hot dog cat } } | |
| let(:splitter) { AnagramPairFinder.new(dictionary) } | |
| describe "#lookup" do | |