Let’s have a look at a first example of writing and running a functional test. This is going to be a very basic hello world example, but still it gives an opportunity of looking at the bare minimum usage of WebDriverIO and a first taste of asynchronous programming with promises. Continue reading Functional Testing Hello World
In the previous series of posts, we’ve explored the basics of unit testing and the principles around it. When developing websites, there is another important type of testing: functional testing (also known as browser testing).
Functional testing is an end to end type of test. Unlike unit tests, we’re not testing the behavior of individual code units but we’re testing the entire system as a whole. It involves writing a script against a browser, simulating a user interaction with the website, and verifying that the end result is what you would expect. This can be as easy as navigating to the homepage and verifying that the footer shows the copyright. But it can also involve more elaborate tests, like registering a new user, adding products to your shopping bag, performing an order, and so on.
Selenium WebDriver is perhaps the most known tool when it comes to functional testing. It operates as a server, implementing the WebDriver API, listening for commands and instrumenting any browser you want. The WebDriver API is so popular that there are even online services like SauceLabs that you can use. There is also PhantomJS, a headless browser (i.e. without any user interface) that implements the WebDriver API. When you’re running your functional tests in your CI server, you typically can’t launch an actual browser, so you can’t use Selenium directly.
In the next posts, we’ll start playing with functional tests. If possible, I’ll try to use WebDriverIO 4 to avoid the extra complexity of async code. We’ll also see how to use the Page Object pattern to make the tests readable and avoid duplication.
In the previous post we had a look at sinon spies. With spies, we are able to determine if a specific function was called or not. Usually the dependencies between units are more interesting, they involve units co-operating, exchanging data and so on. Spies do not suffice. Let’s have a look at another technique, using stubs. Continue reading Using sinon stubs
In the previous post, we implemented a new feature for our calculator: it makes a bell sound when you divide by zero. The bell is a simple function that the calculator calls and it is provided as a constructor dependency. We wrote a unit test for this as well, but the code for that is a bit verbose. Let’s see how we can use a mocking library like sinon to reduce and standardize the testing code. Continue reading Using sinon spies
We left our calculator in the previous post in a decent state, being able to do the four basic mathematical operations. In the special case of division by zero, we want the calculator to make a noise like a bell. Let’s see what we can do about this. Continue reading The division by zero bell – Dependencies in unit tests
Last time we had a look at test driven development and our calculator learned how to do multiplication. In this post, we’ll add division and talk a bit about code coverage and unit test quality.
Let’s continue building up our calculator with more mathematic operations. So far we have addition and subtraction, so multiplication comes up next. In this post, we’ll have a look at test driven development. Even though the examples are a bit trivial, I hope they’ll outline the important points. Continue reading What is Test Driven Development?
In the previous post we started writing a basic Calculator class and added the first unit test. Let’s have a closer look at that unit test and extend our calculator with more features.
So, let’s start with some basics. What is a unit test? A unit test is a piece of code that validates the expected behavior of a unit in isolation. I guess the next question is, what is a unit? A unit is the smallest piece of code in a given programming language. Typically that is a function or a class method. Let’s see it with an example.