To start (assuming you already have behat installed), install grunt-parallel-behat using npm:
npm install grunt-parallel-behat
By default the tool will assume the behat.yml is in the same folder as the grunt file and it will run any feature files under the current directory.
To run, execute following within your behat root folder:
Note: This would run as if all tests are to be run in parallel, i.e. 1 per thread – to be specific about batches, and adding behat parameters, below is an annotated example of a working Gruntfile.js:
flags: '--tags @wip'
You can write BDD features how you want, but always observe Gherkin-language approach. Most BDD tools support this language, but this by means means constricts you. You take the base, and build on it. And specifying requirements this way enables taking a common approach easier to maintain. What your product owners and stakeholders need to know is why they are doing them in this way. With Agile, people were used to defining nice easy 3 lines user stories – little interest in the collections of tasks that the team work out in planning, in order to acheive what they believe is the intention.Breaking a user story into features, and broken down into scenarios provide even more direction for development, and just as importantly, highlights risks and potential blockers.
Read more →
When the fashion becomes bigger than the substance in tech world, I naturally resist its pull. The substance gets diluted, re-branded, and owned after lengthy patent suits. The same goes for electronic music, for me. After 1994, when the Criminal Justice Bill pushed parties back into commercial clubs, business worked out ways to clone and market it. Much of dance music in underground scene, provided the drum sounds for the drum machines still used today. Music and tech – standing on shoulders of giants, always.
Take the wonderful world of the web. The first online ad appeared in 1994.
The first tv advertisement appeared for the internet in 1994 …
Read more →
This is down to tester and developer perceptions of what “Behaviour” means – and perceptions that are BOTH valid. The tester looks at feature files (i.e. user story plus scenario(s)), and sees them as the acceptance tests. Behind the scenario statement lines is where the tester will add code to automate the test. The back-end developer will look at the feature files, and immediately think in terms of development tasks and dependencies needed to perform the functionality (i.e. pure functional behaviour). The front-end developer will take UX and design cues from the feature files directly.
Read more →
Does methodology really make anything any better? I think it’s better to latch onto the principles that underpin Lean, Agile, Scrum et al. The principles are sound software engineering and project management ones. Ones that predate any of the current favourites. Iterative and incremental development, continuous integration, automated testing … these have been around for decades. If you need an analogy, think of true innovators in tech – it isn’t Apple, Microsoft, Facebook etc. They used what was already there, and commodotised them effectively. Who invented C, or the GUI, or the mouse? Does anyone care? Iterative and Incremental development has long history ….
IID [terative and Incremental Development] grew from the 1930s work of Walter Shewhart, a quality expert at Bell Labs who pro-posed a series of short “plan-do-study-act” (PDSA) cycles for quality improvement. Starting in the 1940s, quality guru W. Edwards Deming began vigorously promoting PDSA, which he laterdescribed in 1982 in “Out of the Crisis”. Tom Gilb and Richard Zultner also explored PDSA application to software development in later works.
Computer Iterative and Incremental Development:A Brief History
I particularly like the fact it was a QA guy behind it – it makes total sense that evolutions of quality and efficiency in coding would come from QA. QA is another area that in fact does not care what badges people carry. We adapt, recommend but ultimately work to same goals of code quality and client satisfaction – and the two are not mutually exclusive. You don’t have to sell good coding, but showing actual coding. It often manifests in performance, usability and maintainability – words a client will understand. Whilst I am a little weary of the same circles that happen with the saleable methodologies, one approach rejuvenated my interest in newer development practices, which as you can tell from most posts over last year, is BDD – Behaviour Driven Development. It can be viewed as a strict Lean approach – the stripped-down development/client model. I like Lean – there is little room for “project wallflowers”.
Ironically, I have been on Lean projects, where management heavily outweigh the number of developers. Such is the pull of these buzzwords, management gravitates towards them like moths to a “another skill for the old cv” flame. I have said it many times, that fundamentally things don’t change that much – a strong team with good cross-functional skills will cut through any methodology bullshit and deliver. My opinion is that it is management that lagged behind, and is still area that can do far more damage than a bad developer ever could. But it is still not seen that way round. If all a manager is doing is acting as interface with a client, then they are simply an obstruction – by Agile or Lean philosophy. Empowering the team does not mean empowering their manager.