Posts tagged with javascript

  • Flaky tests

    A flaky test is a test that can flip from success to failure without any code change. Such failures can be annoying and difficult to diagnose. In this post, I’ll focus on browser tests, where flaky tests can happen more often.

  • A CLI comparison of Java, JavaScript and Python

    The inspiration for this post is the Python, Ruby, and Golang: A Command-Line Application Comparison published on Real Python.

  • npm login credentials on the CI server

    In a previous post, I was discussing a way to publish an npm package to the public npm registry. A big prerequisite for that to work is that you have previously logged in to the CI server in order to authenticate against npm. But we can also fix that manual step and integrate it in the build.

  • Automatic versioning of npm packages

    When you are the maintainer of an npm package, you need to do some administrative work around its versioning. When you release a new version, you need to make sure the package.json is updated, the package is correctly uploaded to npm registry, the git repository is tagged accordingly and so on. You shouldn’t be doing these things manually if you can automate them.

  • Functional Testing - WebDriverIO Integrated Test Runner

    In the previous series of posts, we had a look at functional testing with WebDriverIO and mocha. We explored the page object pattern and saw the challenges of asynchronous programming with promises. We even saw some ways of mitigating those challenges. However, there is another approach to the same problems. Instead of running our tests with mocha, we can run them using the integrated test runner of WebDriverIO. From version 4 onwards, I’ll quote from their site, “the integrated test runner allows you to write asynchronous commands in a synchronous way so that you don’t need to care about how to propagate a Promise to avoid racing conditions”. If you’re starting a new project, or if you don’t have many tests to migrate, this is definitely an interesting approach. This combines a synchronous-like approach without using anything extra.

  • Functional Testing - Hiding Async

    In the previous post, we explored the Page Object pattern and rewrote our tests to use this technique. Sometimes, it can be that the tests appear to be a bit verbose due to the usage of promises. Additionally, promises and asynchronous programming in general can be somewhat confusing to developers. Let’s see some ways of making the tests shorter and easier to read.

  • Functional Testing - Page Object Pattern

    So far, we’ve seen how to write functional tests using the WebDriverIO API directly. Let’s see what problems we may encounter with that and how the page object pattern comes to rescue. Our example functional tests work against Google’s homepage. One test verifies that the search text box exists and it’s visible. Another test types something into that search text box and performs the search. In order to identify the text box, we use the same selectorinput[name=q]. The problem starts here and it’s not unique to functional tests: it’s copy pasting around magic strings.

  • Functional Testing - Dealing with failed tests

    In the previous post, we wrote some functional tests and we encountered our first failing test. Let’s see how we can go about investigating these failures, both on a developer machine and during continuous integration.

  • Functional Testing - Selectors

    So far, we have essentially only one test, a test that verifies the title of the browser. Let’s try to make a more interesting test. We’ll need to interact with elements on the page and simulate the user’s journey.

  • Functional Testing - First steps towards a framework

    Before we go any further, let’s take a break and add a bit of a structure to our functional tests. This will allow us to reduce the code we have to write for each test. We’ll also start thinking about how to organize the tests into folders and files.

  • Functional Testing - Reducing Code Duplication

    Let’s continue our functional testing examples by adding a few more tests. This will demonstrate why we need to start thinking about the structure of our tests and why we should be developing a framework that will allow us to write less code. Let’s add one more test. We already have a test that verifies Google’s homepage title. We’ll do the same for Yahoo’s homepage. By the way, maybe it goes without saying, but normally you would be verifying your own site, during development and CI.

  • Functional Testing Hello World

    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.

  • What is functional testing?

    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).

  • Using sinon mocks

    In the previous posts we had a look at sinon spies and stubs. There is one more technique we can use in order to orchestrate our test dependencies: mocks.

  • Using sinon stubs

    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.

  • Using sinon spies

    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.

  • The division by zero bell - Dependencies in unit tests

    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.

  • A closer look to a basic unit test

    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.

  • On the left-pad drama

    This week the internet exploded in drama after 11 lines of code got unpublished from npm. If you didn’t read about it, the summary is that the developer of left-pad removed his package from npm, after npm renamed another package of his because of some name conflict with some other company’s trademark or so. Lots of other packages broke because of this due to the missing dependency. What is interesting here, is that this removed left-pad package consists of a single function (only 11 lines of code). How can that tiny package break the internet?

  • GitHub badges

    You may have noticed that a lot of GitHub projects have some badges in their homepage, showing for example the status of their latest build. For a node (JavaScript) project, you can use a few more badges to show the world that everything is in order.

  • Chai as promised with Chai string

    Here’s a small tip that puzzled us at work the other day for a while. How do you use chai-as-promised together with chai-string?

  • JavaScript Static Code Analysis, part 2

    In the previous post, I talked about static code analysis and how it can be useful in enforcing and maintaining a consistent coding style, but also in catching subtle bugs and code smells. The focus was on two tools, jscs and jshint. What other tools and techniques can you use?

  • JavaScript Static Code Analysis

    Reading code is hard. It’s often difficult to understand what the developer was trying to express when he was writing that function. If you keep your old projects around, go ahead and open them. You’ll probably struggle to read even your own code. It might even look as if somebody else wrote it.

  • Adventures with automated browser tests in JavaScript

    This is a long post, be advised! It goes through the adventures we have had at work with automated browser tests in JavaScript. It has been a journey full of challenges and knowledge build up, a journey that still goes on!

  • Introducing generator-csharp-cli-app

    In the weekend I experimented with Yeoman and I created my first generator. This is also the first time I publish a package to the official npm repository, so double fun.

  • Custom progress indicator for UpdatePanel

    In ASP.NET the UpdatePanel can help you create an AJAX experience very fast and easy. It is typical to provide some visual element in the page that indicates that the AJAX request is been processed. This can be an animated image, a simple text message, a pretty modal box with a nice shadow effect - anything that does the trick and tells the user that the page is not broken but it’s busy.

This site uses third party cookies from Google Analytics and Google AdSense Accept and close popup