dsl (9)


Testing REST API with Cukes




Gherkin to page object, in easy steps


Feature: As a user,
  I want to be able to see accurate count of search terms in search results.

Scenario: Check for search term count on page
    
Given I am on the homepage   
And I fill in "Behat" for "s"
    
And I press "Search"
    
Then I should see "Behat"
    
And count of "24" instances of "Behat" exists on page

Lets take the last step and follow it through to the test code. behat uses regex to parse the natural language line, to map to particular test code, in this case the countTheElements function.


/**
 
* @Then /^count of "([^"]*)" instances of "(?P[^"]*)" exists on page$/
 
*/

public function countOfExistsOnPage($count, $area)

{
    
# calls the Homepage class which contains the test function code
$this->getPage('Homepage')->countTheElements($count, $area);

}

Test code can get messy quickly, so following page objects approach is sensible both for readability and reusability.

So the actual functional code is stored in another file. This approach means both the Gherkin AND code is more reusable.


namespace Page;

use SensioLabs\Behat\PageObjectExtension\PageObject\Page;
use Behat\Mink;

class Homepage extends Page
{
.............
/**
 
* @param string $count
 
* @param string $area
 
* @return Page
 
* @throws \Exception
 
*/

public function countTheElements($count, $area)

{
    
$str = $this->getDriver()->getContent();
    
$count2 = substr_count($str, $area);
    
if ($count != $count2) 
{
        
throw new \Exception($count . ' is incorrect, it should be: ' . $count2);
    
}
;

}



Inspired by Behat

Pride comes before a fall – A person who is extremely proud of his or her abilities will often suffer a setback or failure, because he or she tends to be overconfident and to make errors of judgment.  Latching onto Agile as a weak guide can give people a false sense of security. 




BDD with Selenium and Fitnesse

How to use Selenium with Wiki tools, for requirements management and BDD.




Smarter architecture with DSL

The soup is SOA with DSL Maybe it’s time to write new language. As a programmer working at a company, you must find yourself writing same chunks of code time and time again. Sure, you build up your own libraries to reuse. And if you are going to do that, why not create a class/function to use that call that code. And you don’t need to just use one programming language. This mentality is not so prevalent in web development. A lightweight, but relevant example is virtually every website will have HTML and Javascript – Javascript is sometimes more appropriate for a given website feature, or simply only possible with it.

What we are doing by accident or by design, is writing our own languages – the fact they are based on 1 or more other programming languages is irrelevant. It feels like its time to re-address how we look at programming languages, as selling up to particular technologies is a dangerous game to play, in the long-term.

It is always a good idea to write a DSL. There is no better way of becoming a domain expert than implementing a custom language for that specific domain.
http://blog.nofail.de/2010/02/writing-your-own-dsl-with-ruby/

Although there have been many benefits of Domain-Specific Languages (DSLs) reported from both academia and industry, implementation of DSLs continue to face challenges with respect to frequent evolution of both syntax and semantics. Some languages are more geared for DLS than others (Ruby is a good example). Techniques for implementing DSLs also lack interoperable capabilities among base languages and limited tool support. Such challenges result in increasing DSL development cost and constrain DSL adoption opportunities. It’s early days – but there is no reason that companies can’t start developing a strategy for DSL projects. No room for individual project politics here – you need cohesion.

Have I been harsh on Ruby on Rails?  Perhaps – as the underlying ethos of RoR does make a lot of sense.  The phrase that always makes me wince is “I can do more with less code”.  That is not necessarily a bad thing – unfortunately the phrase also has an association with lazy development (developers). Ongoing programming library development, new helper objects, are all part of the programming evolution. But it can be done badly. You can’t have developers who only understand their programming environment from component perspective, and issue diagnosis will involve lower level understanding.

Software that used to be an entire system, has become a component, and that seems perfectly logical. A CMS (Content Management System) is one of them – a common set of features that becomes a feature itself. If your company developed software on SOA principles, you would be surprised by how much work can be save in the long-term. There are many commonly used features in application development, and none more so than on web applications. It is far easier to present requirements in form of components, and the more advanced and flexible these components are, the easier it would be to implement them in code closely to requirements. Clients are generally asked to think too granular these days – I mean, does the client really need to have an opinion on password length? There are a lot of standards on the web, and it is advisable to follow those standards.

To effectively share and reuse of your DSL, it is necessary to provide a consistent programming environment with clear set of limitations and rules. This is called the Application Programming Interface (API).  An API is an essential part of Service-Oriented architecture, as well as any other software architecture, because it can be used as independent logical layer. Below is very simple representation of SOA, which has been largely misunderstood (or more correctly, underestimated).

The key to SOA is the business logic layer (i.e. potential shared services). And this is where DSL comes in, or should do. DSL transforms programming logic, into architectural logic. Computers are only going to be as dumb as we make them.