Problem 1 entails figuring out the sum of numbers divisible by 3 and 5:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.

I thought it would be interesting to see if I could solve this in Groovy as the solution clearly deals with iterating over a series of numbers — and as everyone who has played with Groovy (or some other dynamic language for that matter) knows, iteration is a blast, baby!

Accordingly, my first pass yielded the following code:

def sum = 0
(1..<1000).each{
 if((it % 5 == 0) || (it % 3 == 0)){
   sum += it
 }
}
assert sum == /* do it yourself, baby! */

Note that I’m using Groovy’s exclusive range feature to easily iterate over all numbers less than 1000. I then proceed to use Groovy’s it variable, which represents the current value in the iteration (i.e. 1, 2, 3, etc) and test the instance with Java’s modulo operator (that is, modulo returns the remainder of division — 10 modulo 5 is 0, but 11 modulo 5 is 1). If there is a match, I add it to the sum variable. This is programming 101 and brought me back to the Age of Aquarius, baby!!

That was easy enough; however, I wanted to see if I could do away with the sum variable by using one of Groovy’s many hip magic methods attached to collections. Thus, my second attempt leverages Groovy’s findAll method, which permits putting a condition in the resulting closure, which then returns a collection meeting that criteria. Accordingly, with the returned collection of numbers meeting my criteria (that is, any number that is divisible by 5 or 3), I then have to issue the sum method like so:

def val = (1..<1000).findAll{(it % 5 == 0) || (it % 3 == 0)}
assert val.sum() == /* you gotta figure it out yourself, man! */

Groovy’s sum method is straight forward — it takes all the values in a collection (presumably add-able) and adds them up!

Admittedly, the second example is a bit harder to read (at first glance, that is) but it sure is a bit more aesthetic than the first brute force bogue example, isn’t it?

While traditional software methodologies have the tendency to segment groups into logical units of responsibility, agile teams favor a more collaborative approach that facilitates working along side various people and groups containing differing skill sets and expectations. That is, for example, the client begins to take responsibility for elaborating expectations through a working effort to understand how the process unfolds. What’s more, by working closely with a client, a team can better understand what is needed and why. As opposed to a test document fashioned from a bogue requirements document (often times done by various teams working separately), leveraging a story in a collaborative manner ensures all parties are effectively on the same page. Thus, the customer (or some proxy there of), development, and QA are working together in the process of constructing stories and indeed leverage the same stories for all related assets.

Because it’s their bag, when Agile teams embrace stories as a fundamental means as to conveying requirements (i.e. features) along with a means for validating them, a natural tendency is for all parties to begin to own quality. That is, since everyone is aware of how to validate a feature, everyone begins to practice validating such features. In essence, a story facilitates leveraging both TDD and functional testing (which are also both automated and exercised via CI) .

What’s more, when the whole team both works together off of the same artifacts that are continuously verified, everyone can better understand the meaning of “done” — that being the question “is feature x finished and ready for the client (or clients) to have?” Of course, if everyone has utilized the same artifact (i.e. a story!) for both building and verifying a client’s expectations, then it is quite easy to check if the feature is done.

Thus, the whole team approach that leverages stories:

• ensures all hip parties see and understand the “big picture” of a particular project
  • that is, why someone wants an application (and its related features) built, which in turn further facilitates whole team ownership (along with more effective testing!)
• helps teams figure out the definition of done

Obtaining these benefits is a matter of providing a means for all parties on a team to collaborate, which is often found in leveraging a story. Plus, visibility into overall team progress as facilitated via CI and automation. The whole team approach also meets the original goal of software testing — that being the assurance that high quality code is delivered to interested parties. Teaming also reduces the tendency to throw up barriers that often plague efficiency.

Agile testing boils down to two fundamental changes, baby, that differentiate it from traditional software testing — both the notion that testing isn’t a phase but a whole life-cycle approach and that the entire team works together towards shared goals. Agile testing complements a highly efficient software development life-cycle and ultimately produces better software faster.

Rather than wait until the end of some period to begin testing, in an agile influenced testing organization, testing is done throughout a life-cycle. Interestingly, the asset that both facilitates collaboration and increases testing productivity is the story. A copasetic story both captures a feature (or requirement) and provides a means for validation; plus, stories are, by their nature, quite easy to collaborate on. In fact, rather than breaking into different groups to diligently define requirements documents, design documents, and test strategies, teams that instead focus on collaboratively authoring stories often times find a much more streamlined approach that lessens the inevitable impedance mismatch that occurs when different groups leverage different mediums (or documents).

In a broad sense, the approach of collaboratively leveraging stories to both define features and verify them can be seen as Test Driven Development. Indeed, depending on your view point, Test Driven Development (or TDD) can be seen as a developmental practice focused on unit testing; however, broadly defined it captures the mantra of agile testing — that is, the story defines both the feature and a means to test the feature. Whether that feature is tested via a unit test or a hip functional test doesn’t matter, man — the point being is that all parties are leveraging the same asset to drive the test. And best yet, the test itself is defined in language that customer can understand and indeed define if they choose to.

Because testing becomes a whole life cycle approach, a fundamental shift occurs with respect to test assets. As opposed to traditional processes where assets differ in implementation, definition and even storage, in an agile testing environment, all tests are assets defined collaboratively and stored along with source code. That is, functional tests are living assets that are managed and versioned just like code. This process has a secondary benefit — QA becomes involved in what’s known as Continuous Integration. Briefly, Continuous Integration (or CI) is the process of continuously verifying software assets. By doing so, defects can be found early — where they are considerably less expensive to address. Thus, CI provides a means to shorten the feedback loop and permits teams to find and fix issues as they arise, which is fundamentally different to finding and fixing defects after a long coding process.

What’s more, in order for QA to effectively leverage CI, automation is a must. That is, CI is an automatic process that doesn’t rely on human interaction; thus, for QA assets to be exercised along side of developmental assets, automation must be utilized. While teams will often inquire as to how much automation must be leveraged, there isn’t a hard and fast number; suffice to say, it’s healthy to grow automation assets over time. There will always be some level of manual tests — whether they be exploratory in nature or simple human verifications (things look correct) but the more automation leveraged, the better.

Thus, embracing a whole life-cycle approach means embracing

• stories as a means to clearly enunciate features and how to verify them
• treating test assets like code assets through
  • SCM
  • CI
• automation at all levels and granularity

The whole life-cycle approach which stresses stories, CI, TDD, and automation has a number of benefits including:

• lowering the overall cost of addressing defects
  • because they are found quicker
• imbuing a stronger sense team camaraderie
• because QA collaborates with development and stakeholders closely and assets are shared across boundaries, baby

Agile testing’s whole-life cycle approach tends to break down traditional barriers that inhibit efficiencies and ultimately leads to better software quicker. Can you dig it, baby?

This handy dandy plug-in along with Groovy’s multi-line Strings makes testing XML GETs, POSTs, PUTs, and DELETEs a breeze with as little code as possible. To get started, you must first install the plug-in like so:

$>grails install-plugin functional-test

Next, create a functional test like so:

$>grails create-functional-test MyRESTfulTest

This command will create a new Groovy file in a test/functional directory. The newly generated Groovy class is an instance of an old style JUnit 3.x test — accordingly, from here you can implement simple test methods in Groovy that have a lot of special methods at their disposal.

For example, to verify an HTTP GET to a RESTful service you can simply write:

void testRESTfulGET() {
 get('/currentComnWidgRes/1200992722')
 assertStatus 200
 assertContent """<?xml version="1.0" encoding="UTF-8" ?>
   <list><currentComnWidgRes id="1200992722">
   <effectiveDate>2009-04-30 00:00:00.0 EDT</effectiveDate><nib>4348.23</nib>
   </currentComnWidgRes></list>"""
}

Note the call to the plug-in’s get method; plus, note how I can compare the resulting response (in XML too, baby) via the assertContent call that can take a multi-line String — isn’t that a snap?

POSTs are as easy too — simply leverage the plug-in’s post method and have at it, man!

void doRESTfulPOST(){
 post("/currentComnWidgRes/"){
  body{
    """<?xml version="1.0" encoding="UTF-8" ?>
      <currentComnWidgResid="6969"><nib>-90.0</nib>
      <effectiveDate>2009-04-30</effectiveDate>
      </currentComnWidgRes>"""
    }
 }
 assertStatus 200
 assertContent """<?xml version="1.0" encoding="UTF-8" ?>
   <currentComnAcctRes id="6969">
   <effectiveDate>2009-04-30 00:00:00.0 EDT</effectiveDate>
   <nib>-90.0</nib> </currentComnAcctRes>"""
}

Note, the post method takes a closure where you can set the body via another closure and like before, you can easily verify HTTP status codes and responses.

Running the plug-in is simple too — simply type:

$>grails functional-tests

This command is quite handy as it fires up an instance of your web application; thus, the Grails Functional Testing plug-in makes functional testing, well, easy. What’s not to like about that?

In the winter of 2001, a group of hip industry visionaries came together in an effort to codify various lightweight development techniques, which had, for the large part, sprung out of a collective frustration over the high rate of project failures which have plagued the software industry for years. In essence, these perceptive individuals knew there was a better way of doing things and they captured the succinctness of what has become Agile in what’s known as the Manifesto for Agile Software Development, which explicitly values:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The Manifesto doesn’t discount aspects such as documentation, plans, or tools (in fact, the authors admit these have value); it simply states that collaboration and responding to change, for instance, are more important in the overall pursuit of project success.

In many cases, organizations can see a direct link between these principles and software development; however, the link to software testing is often viewed (incorrectly) as tenuous. By examining the manifesto’s tenets closely, one can begin to discern that they are broad enough to fit all categories and phases one can divide the software life-cycle into. In fact, for those practitioners that have embraced Agile and successfully employed it throughout a software life-cycle have found, Agile testing boils down to two fundamental changes that differentiate it from traditional software testing. Those two facets are:

• software testing is no longer a phase — it is part of the life-cycle — in fact, in a broad sense, both testing and development combine into what is largely known as Test Driven Development
• everyone works collaboratively as one team rather than separate groups responsible for various aspects (i.e. everyone is accountable for quality)

Thus, while the goal of software testing remains the same, the manner at which it is achieved changes slightly in favor of a more adaptive approach that seeks to keep all parties informed and responsible.

Luckily, you can easily enable SQL logging without having to mess with Log4J configurations (i.e. debug, error, warn “packages blah blah”). In the DataSource.groovy file in your project’s grails-app/conf directory, simply add the loggingSql variable to a desired dataSource closure (that is, you can enable this feature for a particular environment or all of them) like so:

dataSource {
  //blah blah
  loggingSql = true
}

After that, you’ll notice that all SQL statements Grails (or really, Hibernate) utilizes will be logged to whichever appender you’ve configured (i.e. System.out, by default). This little tip has proved quite copacetic for me, man! Can you dig it?

Software testing, in the traditional sense of the phrase, is usually a phase towards the latter cycle of product development; that is, it happens somewhere before product delivery and after the development team finishes writing code. In fact, in many cases, traditional software testing is last check that “ensures a product is ready for delivery” (i.e. that the code is of high quality, has few to no defects, is ready for customer interactions, etc). Yet, as anyone who has ever lived through this process knows

• it’s impossible to imbue quality into something that’s already been built (that is, quality is something that’s built in, man)
• the longer the development cycle lasts, the harder it is to fully test the finished product (that is, at some point the time required to fully test a software application exceeds the expectations for delivery)
• the cost of going through the “find and fix the bug” cycle is by this time increasing by the day (i.e it is a well known facet of software development that the cost to address a bug increases at a tremendous rate the longer it resides in software)

Plus, this last step before going live often becomes a veritable gate (sometimes even referred to as the “quality gate”), which frequently pits two competing expectations (and their respective organizations) against each other. On one side, development is motivated to push their product live and QA is motivated to fix issues before pushing the product live (which means more work for development!). Thus, one side is appearing to push one way and the other side is appearing to push the other way. In many cases, this competing interest yields walls that unfortunately act as a barrier to efficiencies, which then pits IT against the business (who is motivated to push quality features live quickly). Now three organizations are pushing against each other!

Thus, traditional software testing’s goal of providing a means to ensure high quality code is released is quite noble; however, in reality, this hip goal is quite challenging to do well in an efficient manner.

Check it out– first, you must create an instance of RESTClient like so:

def zorillo = new RESTClient("http://acme.zorrillo.com/")

Because it’s my bag, I’m interacting with a service whose base URI is acme.zorrillo.com. With this instance, I can easily obtain information via an HTTP GET like so:

def res = zorillo.get(path:"widget/1010081127")

In the above code, I’ve issued a GET request to http://acme.zorrillo.com/widget/1010081127, which returns an XML response that looks something like this:

<widget id='1010081127'>
 <type>JPM</type>
</widget>

Interestingly, with an instance of a response (in my case, res), you can grab an instance of the returned XML via the data property, which is the root node returned via Groovy’s hip XMLSlurper. Thus, data points to the widget element; consequently, I can grab the attribute id and the corresponding element’s value quite easily:

assert res.data.@id.text() == '1010081127'
assert res.data.type.text() == 'JPM'

Need to post some data? That couldn’t be easier either, man — simply use RESTClient’s post method, which allows you to use a MarkupBuilder to construct corresponding XML like so:

def ans = zorillo.post(path:"widget/",
		requestContentType: XML,
         body: {
           widget(id:'129033'){
             type("TFR")
          }
        })

Note in this case, the POST URL is http://acme.zorrillo.com/widget/ and I’m posting a document which looks like so:

<widget id='129033'>
 <type>TFR</type>
</widget>

But, because I’m using Groovy’s MarkupBuilder I don’t have to deal with XML directly — not bad, eh? The /widget service returns an XML document of the created widget if everything works; thus, I can verify things are kosher like so:

assert ans.status == 200
assert ans.data.@id.text() == '129033'
assert ans.data.type.text() == 'TFR'

How’s that for easy, man? The next time you need to interact with a RESTful web service, consider using Groovy’s HTTPBuilder — it’s a snap!

then "the cell returned should be a date type", {
 sndcells = sheet.getRow(1)
 dtype = sndcells[2].getType()
 if(dtype == CellType.DATE){
  dt = sndcells[2].getDate()
  dt.getTime().shouldBe 1201737600000
 }else{
  fail "the type obtained wasn't a date, but was a ${dtype}"
 }
}

In the code above, which is a copasetic snippet of a larger story on parsing an Excel template, I’m verifying that I can obtain a Date type from a particular cell represented as a string (i.e. 1/31/2009). As you can see, if the dtype variable is of a desired type (i.e. Date), I can easily validate it via the shouldBe phrase. If for some reason, however, the cell I expect isn’t a date, I can force easyb to fail by using the fail phrase, which takes a String (note how you are free to use Groovy’s groovy GString feature in the phrase as I’ve done with ${dtype}).

Of course, I could have omitted the else clause entirely; however, in that case, I wouldn’t explicitly know that a particular scenario failed! Can you dig it, baby?