# Turing completeness

sed is a very powerful tool. A simple sed statement may turn a cat into cement. Observe: echo cat | sed statement I was asked by mariom@ircnet whether is it possible to implement the Euklidean algorithm (the one that computes the greatest common divisor) in awk. awk is a Turing complete language, so the answer is yes, it is possible. There is a snippet proposed by mariom:

```{
a = \$1;
b = \$2;
while (b != 0) {
c = a % b;
a = b;
b = c;
}
print a
}```

Anyway, my response was that it is possible even in sed. Is it? Of course! Sed is a Turing complete language. Though I had no idea how to write it in sed. I use sed for simple substitutions only, but I could not admit that! I started googling for arithmetic operations in sed and I found

a dc implementation in pure sed. So the next question is how to implement the Euklidean algorithm in dc. It turned out to be quite simple, see:

`[lalb%sclbsalcsblb0`

This code assumes that there are two integers on the stack. So you can test it with something like that:

`echo '20 25 [lalb%sclbsalcsblb0`

Let’s analyze what is happening there. There is F macro that is equivalent of “while” loop in awk code. It

loads the values of a and b registers on the stack. Then replaces them with their reminder and saves it in the c registers.

`lbsalcsb`

statement just copies the value of

b to a and c to b. Finaly it compares the value of b with 0. If former is greater it executes F (note: recurrence. It is the only way to implement a loop in dc). Otherwise it quits.

`sasblFxlap`

statement is an entry point. It saves values from stack in the

a and b registers, then executes F and prints the content of the a register. So this sed script is an equivalent of awk script that executes Euklidean algothm. Now it is enough to embed the dc script into dc.sed, et voila! Enjoy: Euclidean algorithm implemented in pure sed.

## Rails Girls Warsaw

Chcecie poznać Ruby on Rails? 29-30.09 w Warszawie odbędą się warsztaty, na których będziecie mieli taką okazję http://railsgirls.com/warsaw.…

## How to use mocks in controller tests

Even since I started to write tests for my Grails application I couldn't find many articles on using mocks. Everyone is talking about tests and TDD but if you search for it there isn't many articles.

Today I want to share with you a test with mocks for a simple and complete scenario. I have a simple application that can fetch Twitter tweets and present it to user. I use REST service and I use GET to fetch tweets by id like this: http://api.twitter.com/1/statuses/show/236024636775735296.json. You can copy and paste it into your browser to see a result.

My application uses Grails 2.1 with spock-0.6 for tests. I have `TwitterReaderService` that fetches tweets by id, then I parse a response into my `Tweet` class.

`class TwitterReaderService {    Tweet readTweet(String id) throws TwitterError {        try {            String jsonBody = callTwitter(id)            Tweet parsedTweet = parseBody(jsonBody)            return parsedTweet        } catch (Throwable t) {            throw new TwitterError(t)        }    }    private String callTwitter(String id) {        // TODO: implementation    }    private Tweet parseBody(String jsonBody) {        // TODO: implementation    }}class Tweet {    String id    String userId    String username    String text    Date createdAt}class TwitterError extends RuntimeException {}`

`TwitterController` plays main part here. Users call `show` action along with `id` of a tweet. This action is my subject under test. I've implemented some basic functionality. It's easier to focus on it while writing tests.

`class TwitterController {    def twitterReaderService    def index() {    }    def show() {        Tweet tweet = twitterReaderService.readTweet(params.id)        if (tweet == null) {            flash.message = 'Tweet not found'            redirect(action: 'index')            return        }        [tweet: tweet]    }}`

Let's start writing a test from scratch. Most important thing here is that I use mock for my `TwitterReaderService`. I do not construct `new TwitterReaderService()`, because in this test I test only `TwitterController`. I am not interested in injected service. I know how this service is supposed to work and I am not interested in internals. So before every test I inject a `twitterReaderServiceMock` into controller:

`import grails.test.mixin.TestForimport spock.lang.Specification@TestFor(TwitterController)class TwitterControllerSpec extends Specification {    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)    def setup() {        controller.twitterReaderService = twitterReaderServiceMock    }}`

Now it's time to think what scenarios I need to test. This line from `TwitterReaderService` is the most important:

`Tweet readTweet(String id) throws TwitterError`

You must think of this method like a black box right now. You know nothing of internals from controller's point of view. You're only interested what can be returned for you:

• a `TwitterError` can be thrown
• `null` can be returned
• `Tweet` instance can be returned

This list is your test blueprint. Now answer a simple question for each element: "What do I want my controller to do in this situation?" and you have plan test:

• `show` action should redirect to index if `TwitterError` is thrown and inform about error
• `show` action should redirect to index and inform if tweet is not found
• `show` action should show found tweet

That was easy and straightforward! And now is the best part: we use `twitterReaderServiceMock` to mock each of these three scenarios!

In Spock there is a good documentation about interaction with mocks. You declare what methods are called, how many times, what parameters are given and what should be returned. Remember a black box? Mock is your black box with detailed instruction, e.g.: I expect you that if receive exactly one call to `readTweet` with parameter '1' then you should throw me a `TwitterError`. Rephrase this sentence out loud and look at this:

`1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }`

This is a valid interaction definition on mock! It's that easy! Here is a complete test that fails for now:

`import grails.test.mixin.TestForimport spock.lang.Specification@TestFor(TwitterController)class TwitterControllerSpec extends Specification {    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)    def setup() {        controller.twitterReaderService = twitterReaderServiceMock    }    def "show should redirect to index if TwitterError is thrown"() {        given:            controller.params.id = '1'        when:            controller.show()        then:            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }            0 * _._            flash.message == 'There was an error on fetching your tweet'            response.redirectUrl == '/twitter/index'    }}`
`| Failure:  show should redirect to index if TwitterError is thrown(pl.refaktor.twitter.TwitterControllerSpec)|  pl.refaktor.twitter.TwitterError at pl.refaktor.twitter.TwitterControllerSpec.show should redirect to index if TwitterError is thrown_closure1(TwitterControllerSpec.groovy:29)`

You may notice `0 * _._` notation. It says: I don't want any other mocks or any other methods called. Fail this test if something is called! It's a good practice to ensure that there are no more interactions than you want.

Ok, now I need to implement controller logic to handle `TwitterError`.

`class TwitterController {    def twitterReaderService    def index() {    }    def show() {        Tweet tweet        try {            tweet = twitterReaderService.readTweet(params.id)        } catch (TwitterError e) {            log.error(e)            flash.message = 'There was an error on fetching your tweet'            redirect(action: 'index')            return        }        [tweet: tweet]    }}`

My tests passes! We have two scenarios left. Rule stays the same: `TwitterReaderService` returns something and we test against it. So this line is the heart of each test, change only returned values after `>>`:

`1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }`

Here is a complete test for three scenarios and controller that passes it.

`import grails.test.mixin.TestForimport spock.lang.Specification@TestFor(TwitterController)class TwitterControllerSpec extends Specification {    TwitterReaderService twitterReaderServiceMock = Mock(TwitterReaderService)    def setup() {        controller.twitterReaderService = twitterReaderServiceMock    }    def "show should redirect to index if TwitterError is thrown"() {        given:            controller.params.id = '1'        when:            controller.show()        then:            1 * twitterReaderServiceMock.readTweet('1') >> { throw new TwitterError() }            0 * _._            flash.message == 'There was an error on fetching your tweet'            response.redirectUrl == '/twitter/index'    }    def "show should inform about not found tweet"() {        given:            controller.params.id = '1'        when:            controller.show()        then:            1 * twitterReaderServiceMock.readTweet('1') >> null            0 * _._            flash.message == 'Tweet not found'            response.redirectUrl == '/twitter/index'    }    def "show should show found tweet"() {        given:            controller.params.id = '1'        when:            controller.show()        then:            1 * twitterReaderServiceMock.readTweet('1') >> new Tweet()            0 * _._            flash.message == null            response.status == 200    }}`
`class TwitterController {    def twitterReaderService    def index() {    }    def show() {        Tweet tweet        try {            tweet = twitterReaderService.readTweet(params.id)        } catch (TwitterError e) {            log.error(e)            flash.message = 'There was an error on fetching your tweet'            redirect(action: 'index')            return        }        if (tweet == null) {            flash.message = 'Tweet not found'            redirect(action: 'index')            return        }        [tweet: tweet]    }}`

The most important thing here is that we've tested controller-service interaction without logic implementation in service! That's why mock technique is so useful. It decouples your dependencies and let you focus on exactly one subject under test. Happy testing!

## Hibernate Envers with Grails 2.1.0

Our client requires that every entity in his Grails application has to be audited with detailed information: who and when did exactly what? It is a perfect opportunity to use Hibernate Envers! It turned out not as straightforward as I thought, so I wa...