# Second assert\_tag failling in rails integration test

**URL:** <https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570>\
**Category:** Rails\
**Created:** [May 4, 2006, 7:54am UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570 "2006-05-04T07:54:15Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 4, 2006, 7:54am UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/1 "2006-05-04T07:54:15Z")

</div>

Hi all,

I’m fairly new to rails and ruby, but I’ve come across an interesting  
glitch and I’m not sure whether I’ve just got something wrong with my  
assumptions or if it really is an error in the underlying framework…

I’ve created a bare-bones set of tests to show you where the problem is.  
What follows are the steps I went through to reproduce the issue.

1. run “rails test”
2. create a controller called “test\_controller”:

class TestController \< ApplicationController  
def one  
render\_text(‘one’)  
end

def two  
render\_text(‘two’)  
end  
end

1. create an integration test:  
require “#{File.dirname( **FILE** )}/…/test\_helper”

class MyTest \< ActionController::IntegrationTest  
def test\_one  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/)  
end  
end

1. ran the integration test.

So, I expected the assertions to all pass, but instead I got the  
following error:

Loaded suite test/integration/test\_one  
Started  
F  
Finished in 0.131389 seconds.

1. Failure:  
test\_one(MyTest)  
[test/integration/test\_one.rb:9:in `test_one' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_controller/integration.rb:427:in`run’]:  
expected tag, but no tag found matching {:content=\>/two/} in:  
“two”.  
 is not true.

1 tests, 3 assertions, 1 failures, 0 errors

As you can see, it successfully passed the match against @response.body,  
but failed the second assert\_tag.

What’s interesting is that if you remove the initial assert\_tag it works  
just fine.

Any ideas?

Taryn

---

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 4, 2006, 8:04pm UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/2 "2006-05-04T20:04:23Z")

</div>

On May 3, 2006, at 10:53 PM, Taryn East wrote:

> end
> 
> Any ideas?

assert\_match /two/, @response.body

–  
Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)

---

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 5, 2006, 2:05am UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/3 "2006-05-05T02:05:25Z")

</div>

On Thu, 2006-05-04 at 11:01 -0700, Eric H. wrote:

> > ```
> > assert_tag(:content => /two/)
> > 
> > ```
> > 
> > end  
> > end
> > 
> > Any ideas?
> 
> assert\_match /two/, @response.body

Yes, well that is the path we are currently forced to take (as you see  
in the example I gave above). But I was still kind of wondering why  
assert\_tag doesn’t work the way that I expect it to.

To give a couple of other examples:

These ones work:

def test\_one  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
assert\_tag(:content =\> /n/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
end

def test\_two  
post(’/test/one’)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/)  
assert\_tag(:content =\> /w/)  
end

These ones don’t

def test\_three  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/) # breaks here  
end  
def test\_four  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
assert\_tag(:content =\> /n/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/) # breaks here  
assert\_tag(:content =\> /w/)  
end

ie - you need:

- multiple assert\_tag calls and at least two post/get calls.
- At least one assert\_tag has to occur both before and after the second  
get/post.
- If there are multiple calls before the get/post - they all work.
- It fails on the first assert\_tag that occurs after the second  
get/post.

What I can only assume (not knowing the underlying architecture) is that  
the first assert\_tag does something to internal variables (the book says  
it “parses the response into a DOM”)… then when the next get/post  
occurs, the response changes… but the next assert\_tag doesn’t check  
that the response has changed - it is still using the old parsed DOM.

Cheers,  
Taryn

---

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 22, 2006, 8:47pm UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/4 "2006-05-22T20:47:36Z")

</div>

On May 21, 2006, at 6:46 PM, Taryn East wrote:

> You know I never did get a real response[1] to this question…
> 
> Does anyone else here actually use integration tests?

I don’t, but I know people do.

> Does they work for you?

They seem to for the people that use them.

> Do you not do what we are doing?

They probably don’t, integration testing isn’t about testing HTML.

> Are we using the wrong kind of test here?

You should be writing functional tests when using assert\_tag.

–  
Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)

---

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 22, 2006, 3:48am UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/5 "2006-05-22T03:48:02Z")

</div>

You know I never did get a real response[1] to this question…

Does anyone else here actually use integration tests? Does they work for  
you? Do you not do what we are doing? Are we using the wrong kind of  
test here?  
Has anybody got any ideas?

To recap on the issue I had:  
the steps I went through to reproduce the issue.

1. run “rails test”
2. create a controller called “test\_controller”:

class TestController \< ApplicationController  
def one  
render\_text(‘one’)  
end  
def two  
render\_text(‘two’)  
end  
end

1. create an integration test:  
require “#{File.dirname( **FILE** )}/…/test\_helper”

class MyTest \< ActionController::IntegrationTest  
def test\_one  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/)  
end  
end

1. run the integration test.

So, I expected the assertions to all pass, but instead I got the  
following error:

Loaded suite test/integration/test\_one  
Started  
F  
Finished in 0.131389 seconds.

1. Failure:  
test\_one(MyTest)  
[test/integration/test\_one.rb:9:in `test_one' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_controller/integration.rb:427:in`run’]:  
expected tag, but no tag found matching {:content=\>/two/} in:  
“two”.  
 is not true.

1 tests, 3 assertions, 1 failures, 0 errors

To give a couple of other examples:

These ones work:

def test\_one  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
assert\_tag(:content =\> /n/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
end

def test\_two  
post(’/test/one’)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/)  
assert\_tag(:content =\> /w/)  
end

These ones don’t

def test\_three  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/) # breaks here  
end  
def test\_four  
post(’/test/one’)  
assert\_tag(:content =\> /one/)  
assert\_tag(:content =\> /n/)  
post(’/test/two’)  
assert\_match(/two/, @response.body)  
assert\_tag(:content =\> /two/) # breaks here  
assert\_tag(:content =\> /w/)  
end

ie - you need:

- multiple assert\_tag calls and at least two post/get calls.
- At least one assert\_tag has to occur both before and after the second  
get/post.
- If there are multiple calls before the get/post - they all work.
- It fails on the first assert\_tag that occurs after the second  
get/post.

What I can only assume (not knowing the underlying architecture) is that  
the first assert\_tag does something to internal variables (the book says  
it “parses the response into a DOM”)… then when the next get/post  
occurs, the response changes… but the next assert\_tag doesn’t check  
that the response has changed - it is still using the old parsed DOM.

Cheers,  
Taryn

[1] Yes, I got Eric’s response of:  
assert\_match /two/, @response.body  
which we are already using… but while it’s possible to write a regexp  
to match on something like:  
assert\_tag(:tag =\> ‘td’,  
:attributes =\> {:id =\> ‘status-cell’},  
:child =\> {:tag =\> ‘img’,  
:attributes =\> {:alt =\> %r’Complete’}}  
)  
it’s really annoying… 😛

---

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 23, 2006, 1:11am UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/6 "2006-05-23T01:11:09Z")

</div>

On Mon, 2006-05-22 at 11:47 -0700, Eric H. wrote:

> On May 21, 2006, at 6:46 PM, Taryn East wrote:
> 
> > Does anyone else here actually use integration tests?
> 
> I don’t, but I know people do.

I haven’t heard anything from anybody else that does… and I guess I’m  
just beginning to wonder…

> > Does they work for you?
> 
> They seem to for the people that use them.
> 
> > Do you not do what we are doing?
> 
> They probably don’t, integration testing isn’t about testing HTML.

We’re not actually testing the html itself, we’re testing the flow of  
screens… which I assumed is what integration tests are for. It’s just  
that to test that we’re arriving at the right screen with the right data  
on it we use assert\_tag.

We also use assert\_response and assert\_template (which seem to be the  
main thing used in integration tests I’ve found) but you have to test  
not only that _an_ edit screen popped up, but that the right one popped  
up - and the way to test that is to check that it was populated by the  
data that you actually asked for. We don’t test that every bit of data  
is there (that’s what I believe belongs in the realm of functional  
testing - though maybe I have that wrong too) but we need to check that  
something is right so for example we check for the existence of one key  
field, or that one input has been pre-populated with previously-chosen  
data. We check that, for example, this occurs whether or not the user is  
still using the same session, or if they login with a different session  
and come to the same page.

If we are doing this in the wrong way then I would be very appreciative  
of any assistance in directing us towards the correct way to test this  
sort of thing.

> > Are we using the wrong kind of test here?
> 
> You should be writing functional tests when using assert\_tag.

Ok, so then what are integration tests for? It’s quite possible that we  
have misunderstood what level of testing we need… but the article I  
read on it here:  
[http://jamis.jamisbuck.org/articles/2006/03/09/integration-testing-in-rails-1-1](http://jamis.jamisbuck.org/articles/2006/03/09/integration-testing-in-rails-1-1)

seemed to indicate that integration tests were used for screen flow…  
which is what (afaics) we are doing.

In any case even if we are using integration tests completely  
incorrectly… there is still a bug in the framework if assert\_tag is  
failing.

Cheers and thanks,  
Taryn

---

<div class="post-metadata">

**Author:** ![Taryn\_East](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/e0b2c6/32.png) [@Taryn\_East](https://www.ruby-forum.com/u/Taryn_East)\
**Post date:** [May 23, 2006, 9:10am UTC](https://www.ruby-forum.com/t/second-assert-tag-failling-in-rails-integration-test/59570/7 "2006-05-23T09:10:27Z")

</div>

On May 22, 2006, at 4:09 PM, Taryn East wrote:

> On Mon, 2006-05-22 at 11:47 -0700, Eric H. wrote:
> 
> > On May 21, 2006, at 6:46 PM, Taryn East wrote:
> 
> > > Does they work for you? They seem to for the people that use them.
> > > 
> > > Do you not do what we are doing?
> > 
> > They probably don’t, integration testing isn’t about testing HTML.

I’m going to take the liberty of rearranging this paragraph.

> we’re testing the flow of screens… which I assumed is what  
> integration tests are for.

Correct.

> We’re not actually testing the html itself, […] It’s just that to  
> test that we’re arriving at the right screen with the right data on  
> it we use assert\_tag.

If you’re using assert\_tag you’re testing the HTML.

assert\_tag tests at the wrong level. Test assigns instead.

Your functional tests should ensure that data on the controller side  
correctly shows up in the right place on the HTML. If you’re using  
assert\_tag you’re testing in two places.

> We also use assert\_response and assert\_template (which seem to be  
> the main thing used in integration tests I’ve found) but you have  
> to test not only that _an_ edit screen popped up, but that the  
> right one popped up and the way to test that is to check that it  
> was populated by the data that you actually asked for.

This is the responsibility of functional tests. When your functional  
tests ensure that data is in the right spot then you can test based  
purely on assigns in your integration tests and cut out a ton of  
(duplicated) code.

> We don’t test that every bit of data is there (that’s what I  
> believe belongs in the realm of functional testing - though maybe I  
> have that wrong too) but we need to check that something is right  
> so for example we check for the existence of one key field, or that  
> one input has been pre-populated with previously-chosen data. We  
> check that, for example, this occurs whether or not the user is  
> still using the same session, or if they login with a different  
> session and come to the same page.

And that data gets there via assigns, so exploit that fact and make  
your tests simpler. The bigger the test the more likely it is wrong.

> If we are doing this in the wrong way then I would be very  
> appreciative of any assistance in directing us towards the correct  
> way to test this sort of thing.

I actually think that even functional tests are too high level, so I  
wrote Test::Rails to break functional tests down into controller  
tests and view tests. I found my functional tests repeating  
themselves too much so I needed to get closer to what the real  
responsibilities of controllers and views are.

Controller tests ensure that URL params map to the correct assigns  
and view tests ensure that assigns map to the correct HTML. Once I  
know these tests all pass then integration tests can rely strictly on  
assigns and I avoid tons of code.

> seemed to indicate that integration tests were used for screen  
> flow… which is what (afaics) we are doing.

Testing is broken into multiple layers. What you test on one layer  
shouldn’t be tested on another. What is tested on one layer you can  
rely on in a higher layer.

Here’s an untested example:

class EntryControllerTest \< Test::Rails::ControllerTestCase

fixtures :entries

def test\_view  
get :view, :id =\> entries(:frogs).id  
assert\_response :success  
assert\_template ‘entry/view’  
assert\_assigned :entry, entries(:frogs)  
end

def test\_edit  
get :edit, :id =\> entries(:frogs).id  
assert\_response :success  
assert\_template ‘entry/edit’  
assert\_assigned :entry, entries(:frogs)  
end

def test\_update  
post :update, :id =\> entries(:frogs).id, :body =\> ‘Frogs rock!’  
assert\_redirected\_to “/entry/view/#{entries(:frogs).id}”  
entries(:frogs).reload  
assert\_equal entries(:frogs).body, ‘Frogs rock!’  
end

end

class EntryViewTest \< Test::Rails::ViewTestCase

fixtures :entries

def test\_view  
assigns[:entry] = entries(:frogs)  
render  
assert\_tag :tag =\> ‘p’, :content =\> entries(:frogs).body  
end

def test\_edit  
assigns[:entry] = entries(:frogs)  
render  
form\_url = “/entries/update/#{entries(:frogs).id}”  
assert\_post\_form form\_url  
assert\_tag\_in\_form form\_url, :tag =\> ‘textarea’,  
:content =\> entries(:frogs).body  
end

end

Now I know that all the URLs and data will show up correctly I can do  
an integration test.

class EntryIntegrationTest \< ActionController::IntegrationTest

fixtures :entries

def test\_editing  
entry = entries(:frogs)  
get “/entry/edit/#{entry.id}”  
assert\_response :success  
assert\_template ‘entry/edit’

```
 post "/entry/update/#{entry.id}" :body => 'Frogs rock!'
 assert_response :redirect

 follow_redirect!
 assert_success
 assert_template 'entry/view'

```

end

end

I already know all the URLs in the HTML will be correct for that  
template so I don’t need to re-test that.

> In any case even if we are using integration tests completely  
> incorrectly… there is still a bug in the framework if assert\_tag  
> is failing.

I know exactly what the problem is, and it isn’t a problem if you  
write your integration tests correctly.

–  
Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)