3

I am trying to understand acceptance tests, but I am confused where it starts or what kind of test/s is/are involved. Do I have to use automating GUI test frameworks or do I have to use unit tests? What is the boundary of an acceptance test?

Edit: My question is about automated acceptance tests.

Rookian
  • 19,841
  • 28
  • 110
  • 180

3 Answers3

2

Acceptance testing is done after the entire application/software is developed and integrated. Acceptance testing is done mainly to test whether the application meets the user requirements.

There are mainly 2 types of acceptance testing.

  • Alpha testing
  • Beta testing

Acceptance testing is mainly done by the client (person who asked for the software to be developed) and end users.

Alpha testing is done by the client. He is helped by the developer. Here the client looks at the software to make sure all his requirements are fulfilled.

Beta testing is done after Alpha testing is completed. Here the application is released to a set of people who behave as end users and use the applications.

altamash heroli
  • 81
  • 4
1

Unit test are not to be confused with acceptance tests.

Acceptance tests are basically requirements, written as tests so that:

  1. It is clear when requirements are met;
  2. Actual testing is easier to plan, and to run.

Unit tests are automated test for small bits of code, used to keep an eye on all the little bits without the need for constant (and much hated) manual checks.

Yehuda Shapira
  • 8,460
  • 5
  • 44
  • 66
  • Yes, but do I need a GUI test tool like Watin or Selenium or are there other possibilites? I heard a lot of times that GUI test tools are cumbersome, bad maintainable and slow. – Rookian Oct 10 '12 at 19:06
0

You can go down the UI road. Selenium or WatiR are solid tools that can be used to run ui-based test suite. If you are Dot.Net developer, you can use WatiN, but the problem with it is that it seems to be pretty much dead, as it had no new version since April 2011.

I did manage to have some decent test suite work for me a while back, integrating SpecFlow (more on that later) and watiN, and it worked fine.

However, as time went by, i realized that when I was doing UI based tests, all i was doing was loading a page, clicking something, and than checking the results in the DB. Sometimes, i also checked that the screen also showed me the expected message, but that's all. That conclusion drove me off UI based testing.

What i started doing, is make sure the UI is built on rules and idioms. The tooling now-days (asp.net mvc, razor templates or better yet - knockout.js) allows us to do so without too much pain. When the UI is built methodically, and not by everybody throwing whatever field they like on the page, most of the time all you need to test is the methods that build it, and not the result. Ofcurse, if i do want to test it (and in some scenarios, you will), it is much easier (and faster) to test it with tools like QUnit,

So my way current of practicing ATDD :

  1. Use specflow to get business requirements into test code.
  2. Test only "code behind".
  3. Use knockoutJS for the UI plumbing (using lots of custom bindings)
  4. Create standards for Models that are returned to the view.
  5. Treat UI behavior tests as unit tests.

Here is a good starting point for specflow: http://www.infoq.com/articles/Spec-Flow

motime
  • 564
  • 2
  • 10
  • I use Machine.Specifications. The problem to test only the "code behind" is that you could have 100% code test coverage, but you still have bugs. The view still has some logic that has to be tested too. And when javascript is also involved it is getting more complicated. http://lostechies.com/jimmybogard/2012/08/22/thatconference-presentation-content-posted-functional-testing-in-mvc/ – Rookian Oct 14 '12 at 10:27