BDD testing using a user interface driver (e.g. Selenium for a web application)

Question

Can I run BDD (Behavior Driven Design) tests using the user interface driver?

For example, when using a web application instead of:

• Writing tests for an external server, and then more tests in Javascript for front-end

Should I:

• Write tests as Selenium macros that simulate mouse clicks, etc. in the actual browser?

The benefits that I see with this are as follows:

• Tests are written in one language, not in several
• They focus on a user interface that makes developers think outside of the box.
• They run in a real runtime (browser), which allows us
  • Testing different browsers
  • Testing different servers
  • Get an idea of ​​real performance

Thoughts?

Answer 1

We did this for a C # application using the WPF testing tool ( WipFlash ) and writing NUnit tests in a BDD-like mod.

eg.

Given.TheApplicationWindowIsOpen(); When.I.Press.OKButton(); The.Price.ShouldBeCalculated(); 

We had to encode a lot of DSL ourselves, of course. But it becomes clear to the business / client.

Answer 2

Try using SpecFlow with WatiN: (I'm not sure if you are using .NET here)

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

Answer 3

For web testing, you can try WebDriver. At the moment, the Selenium team is busy integrating WebDriver. Google Simon Stewart, who created WebDriver, wrote here about how it works differently in Selenium.

WebDriver uses different technologies for each browser. For Internet Explorer, WebDriver uses Microsoft UI automation, the same technology that WipFlash mentioned by @Brian Agnew on. It's so close that you can pretend to be click buttons. Simon's blog shows why this approach can be more powerful than Selenium Javascript.

WebDriver is available on the Selenium website, but is not yet fully implemented as part of Selenium.

Answer 4

For BDD and any use-case tests, it is important to be able to report what the test does. The problem with many test suites is that no one can say for sure what the test does. This very often occurs if you write in a non-specialized language. Specialization does not necessarily mean a particular language, but abstractions in one language are enough, so it’s clear what is happening.

For example, many tests have code that looks like this (pseudo-code, I will not choose any particular structure):

 object = createBrowser() response = object.gotoURL( "http://someurl.com" ); element = response.getLink( "Click Here" ); response = element.doClick(); 

It’s hard for someone to quickly translate to a business driver (perhaps a product manager or user). Instead, you want to create specialized functions or a language if you are adventurous, so you can have this:

 GotoURL http://someurl.com/ Click link:Click Here 

Selenium and its macros or interface are still pretty low in this regard. If you use them, at least create some wrappers around them.

You can also use a product called TestPlan . It has Selenium in the background and provides a high-level API and customizable langauge for testing. It also goes beyond the Internet only, including email, FTP, etc. The language of the example above is a TestPlan fragment

Answer 5

You can, of course, do some of your acceptance tests this way, but I think most BDD proponents would not recommend using this for all tests. And, of course, true BDD proponents would not call them trials ...

The RSpec Book stands for a two-level cycle with acceptance tests (or scripts) written first (primarily in Cucumber ) and unit tests written (in RSpec ) in an internal cycle more reminiscent of traditional TDD.

An external acceptance test cycle can also use tools such as Selenium to manage the entire application through the user interface (and the authors of the RSpec book talk about this chapter). But this is not suitable for unit tests.

Tests that implement the entire application through the user interface are harder to make repeatable and tend to be slower and more fragile than unit tests.

Answer 6

In fact, you can do both, create a user interface for the driver (agnostic GUI / tech / impl). You can then write UIDriver and APIDriver and select a driver to run a specific test. Launching through the user interface is usually slower (from proc, control repaints, but somehow first creates a higher level of confidence). Running through the API is much faster (in proc, ease of installation).

The trick here is to separate "What from how." Otherwise, you will get to ObscureTests and get a high level of service. Make sure that the focus is on testing, not automation.