Skip to main content

Simple code: Acceptance tests

Acceptance test are a great tool to verify that the application or system works as expected from end to end. Sometimes these tests can be called as end-to-end tests but sometimes end-to-end tests have a different meaning. Another term to describe the same functionality is QA tests and a subset of acceptance tests is often referred as smoke tests.

The idea

The idea is to define a input and the expected output and once the system and all it's dependant services are running the whole system can be verified to work as expected. In a ideal world the acceptance tests would be implemented based on the acceptance criteria of the use case.

The implementation

Acceptance tests can and should be implemented in the code just like unit and integration tests are implemented. The acceptance tests don't neccessarily reside in the same code repository as the code but they can, depending on what's the need.

When a system is API the acceptance tests could be e.g. predefined HTTP requests with predefined responses. These type of tests could easily be implemented with any unit test library or with a help of tools like SoapUI or Postman.

When a system is a web application that's used via browser the tests could be a flow of navigating the application with a browser and verifying that the interactions work as expected. These type of tests can also be easily automated with tools like testcafe and cypress.
Similar tools exist for mobile applications.

Acceptance vs integration tests

Acceptance and integration tests seem very similar and they are. They do basically the same thing but they do it in a different environment. Where a integration test (my idea of a integration test) is executed as part of the systems automated tests in the developers computer and in the CI system the acceptance test is executed against a real system running in a real environment where all the dependant services are running on their own and we as developers aren't neccessarily controlling the system but just executing the tests and observing the behaviour. Acceptance tests can and should also be run automatically by the CI system

When to implement acceptance tests

Just like any other tests acceptance tests can be implemented at any phase of the development process. Sometimes acceptance tests are implemented by someone else than the developer of the system e.g. a QA/tester who's a expert in these type of tests.

One approach is to implement acceptance tests before any code is written. This enables the development of the system with a test driven approach that's called acceptance test driven development i.e. ATDD. Another form of this is called BDD i.e. behaviour driven development.

Next part

In the next part I'll be moving from testing to version control systems and the importance of work log.




Labels:
Location: Espoo, Finland

Popular posts from this blog

Simple code: Immutability

Immutability is a special thing that in my mind deserves a short explanation and praise. If you're familiar with functional programming you surely recognice the concept of immutability because it's a key ingredient of the paradigm. In the world of object oriented programming it's not as used and as easy to use approach but there are ways to incorporate immutability to parts of the code and I strongly suggest you to do so. Quick intro to immutablity The basic idea of immutability is unchangeable data.  Lets take a example. We have a need to modify a object's property but because the object is immutable we can't just change value but instead we make a copy of the object and while making the copy we provide the new value for the copy. In code it looks something like this. val pencil = Product(name = "Pencil", category = "Office supply") val blackMarker = pencil.copy(name = "Black marker") The same idea can be applied in functions and metho
Read more

Simple code: Readability

Readability, understandability, two key incredients of great code. Easier said than done, right? What one person finds easy to read and understand another one finds incomprehensible. This is especially true when programmers have different levels of understanding on various subjects e.g. object oriented vs. functional or Node.js vs. Java. Even though there are obvious differences between paradigms and programming ecosystems there are some common conventions and ways to lower the barrier. Different approaches It's natural that in programming things happen sequentally e.g. you can have a list of objects and you need to do various things to the list like filter some values out and count a sum of the remaining objects based on some property. With the given list const stories = [   {name: "authentication", points: 43},   {name: "profile page", points: 11},   {name: "shopping cart", points: 24},   {name: "shopping history", points: 15},   {name: &qu
Read more

Simple code: Unit tests

Unit tests are the developers number one safety net. Let that sink in. This is the number one reason for writing unit tests. Unit tests are written by developers for developers to ensure that the code works as expected and handles happy and sad paths correctly. With enough unit test coverage the tests enable a safe environment for refactoring and rewriting code. Unit test scope Unit test should test a single thing, a method or function call and it should test only one use case within. In other words a unit test should test a function with a single input. This is a important guideline to understand. When a unit test tests a function with single input it makes the test isolated, repeatable and predictable. Example of good tests: @Test fun findsAddress() {   val address = findAddress("Stevens street 35", "Southport", "Australia")   assertThat(address).isNotNull() } @Test fun doesNotFindAddress() {   val address = findAddress("Stevens street 697", &q
Read more