MVC3/Razor Best BDD practices?

[Pedro G. Dias]

I had a discussion with my colleagues earlier today about how to run
our scenarios.
We are in a rather large project where my team has been working on a
WCF backend, whilst another team have developed an ASP.NET MVC3
frontend.
Now that we are going into early beta/performance tuning stage, the
two teams have consolidated into one, and so, we now develop scenarios
for the bugs (missing scenarios) and rewrites that come up.

What I see, is that the front-end team has taken what seems to me a
rather complicated approach to BDD. They run ALL scenarios through a
combination of selenium and deleporter with sauce labs, so we're
basically hosting all our scenarios on an IIS server, mocking
dependencies with deleporter, and hitting it from sauce labs website.
It's quite sexy to look at, but I'm not sure I see the need for all of
that for every scenario.

I'm 42, and been a geed since early 80s (ZX-Spectrum 48k). I see
patterns such as MVC, MVP, MVVM and so forth as patterns that are
there to help us get rid of UI tests, and make it easier to verify
business logic from the comfort of a coded test. As such, I would
believe that writing scenarios and testing them against the
controller, verifying that it returns a view with a model that can be
tested is a "desired" way to do BDD on ASP.NET MVC projects, and using
selenium/saucelabs/deleporter more in acceptance-tests (which, in my
view, BDD is not about). Being 42 also makes me old enough to read up
on things before I "like" or "dislike" anything - but in this case,
googling on BDD/MVC gives a heavy load of examples supporting MY view,
and googling SpecFlow/Selenium gives a whole host of posts supporting
more use of Selenium.

Assuming that you guys in this group are over averagely interested in
BDD, I know I am, I would like to hear your opinions on the matter.

[pongguru]

I'm 40, and very passionate about the quality of code. Until four
years ago I achieved the quality via integration testing. I started
doing unit testing after I understood it's power. Unfortunately, the
chance I had to do some unit testing was an year ago. The projects I
have been involved in the past year and even the current one don't
have resources to write unit tests. With minimum resources, the
company is trying to release web applications not looking at the
quality that can save the bottom line. Lucky you in that aspect.

As long as you don't have a lot of business logic in the controller,
the unit testing of an MVC application can end at the controller
level. The layers behind it like app service, business domain need
unit testing. In my opinion BDD has to integrate with the business
domain and these lower layers, and expose a UI for the business people
to test if needed. This is where specflow comes as a BDD tool.

I have a different idea on selenium. It should not be used for BDD. It
is for acceptance test as you said.

On Mar 2, 11:47 am, "Pedro G. Dias" <pedro.digitald...@gmail.com>
wrote:

[Darren Cauthon]

Pedro,

I agree with you, and SpecFlow does not require or even lean towards
testing through the UI. I've seen many who say we should, that we
should test the "entire" application, but you can also find the other
side.

Personally, I think complexity kills automated tests, and introducing
the UI is one of the most complex things you can bring into tests.
The UI adds other potential failures, it makes faking parts more
difficult, it slows them down, and it makes asserting results
difficult. I mean, how could it not? The UI has a very limited view
of the application, and running the website has to happen through a
web server which will happen on a different process makes it hard to
test results.

I've had much more success testing against the controller level with
ASP.Net MVC. Everything happens within the same thread, you can
easily create everything that goes in, everything that comes out, and
you're missing only the views.

It makes for a nice BDD cycle, too. You can start the story like
this:

When I enter the following values into the contact us form
| Name | Email | Message |
| x | y@z | test m |
Then I should be sent to the contact us confirmation page
And an email should be sent to 'y...@z.com' saying 'Thanks!'

You can write this story, let it go yellow, and then let the specs
drive the code. The story will force you to define only the input,
the output, and the initial controller until you finally go from
yellow to red. Then you can TDD with unit tests cycling through red
and green until that original story goes from red to green as well.

It's kinda fun to have a continually failing story that suddenly goes
green when one of of your unit tests go green. It's like parts of the
puzzle that suddenly snap together. :)

This isn't anything I made up myself, the RSpec Book taught me how to
do this (even with SpecFlow).

And SpecFlow has some great tools for writing those external setups
and for asserting results afterwards, *cough cough*.

:)


Darren

On Mar 2, 11:47 am, "Pedro G. Dias" <pedro.digitald...@gmail.com>
wrote:

[Gáspár Nagy]

I agree with you all guys. The controller-level BDD experience really
rocks, nothing compares to that. But I have seen many teams using
SpecFlow where they have finally went into the web testing direction.
These are the usual arguments:
- If the application is AJAX intensive, there are quite much logic in
the web part, that is anyway harder to test with classic approaches.
- The ASP.NET MVC framework can do quite much on top of the
controllers: bindings, filters, validation, path routing, etc. With
controller-level testing, you are bypassing these.
- If a feature is a combination of UI (javascript, WPF xaml, etc.) and
backend (from controller on) logic, it is hard to find the right way
for testing it half. This can be a source of an endless discussions.
- The automated testing efforts are significant, even if you do it
over the controller. If such investment is made, business is
interested in guarding the end-to-end quality.

I'm not saying that these apply for all projects, but should be
considered. In some of our project we also use the MvcIntegrationTest
framework from Steven Sanderson as an in-between solution.

For me, personally, there is no _fundamental_ difference of the two
testing approaches. Controller is just an in-between layer of your
application and has no relevance of the "behavior", that BDD suppose
to target. It's another question that the through-UI testing has much-
much less good and reliable tool support. So my hope is, that as the
UI testing (and implementation) tools and practices improve (and they
are improving quite fast), the difference will be smaller and smaller.
So with one hand of mine, I do my controller-level BDD tests
(accepting it as a good compromise), but with the other hand i'm
trying to improve the tools to make the UI testing better. Nice
mission, isn't it? ;-)

Br,
Gaspar

On Mar 4, 6:18 pm, Darren Cauthon <darrencaut...@gmail.com> wrote:
> Pedro,
>
> I agree with you, and SpecFlow does not require or even lean towards
> testing through the UI.  I've seen many who say we should, that we
> should test the "entire" application, but you can also find the other
> side.
>
> Personally, I think complexity kills automated tests, and introducing
> the UI is one of the most complex things you can bring into tests.
> The UI adds other potential failures, it makes faking parts more
> difficult, it slows them down, and it makes asserting results
> difficult.  I mean, how could it not?  The UI has a very limited view
> of the application, and running the website has to happen through a
> web server which will happen on a different process makes it hard to
> test results.
>
> I've had much more success testing against the controller level with
> ASP.Net MVC.  Everything happens within the same thread, you can
> easily create everything that goes in, everything that comes out, and
> you're missing only the views.
>
> It makes for a nice BDD cycle, too.  You can start the story like
> this:
>
> When I enter the following values into the contact us form
> | Name | Email | Message |
> | x    | y@z   | test m  |
> Then I should be sent to the contact us confirmation page

> And an email should be sent to '...@z.com' saying 'Thanks!'