|
|||
|
I’ve previously described how to run your QUnit tests and produce a coverage report on every commit. This works great if you happen to have chosen QUnit as your unit testing framework. Jasmine is another popular JavaScript unit testing framework. Here I will show how you can get the same automated feedback from your Jasmine . . . → Read More: Run all your JavaScript Jasmine tests on every commit Being able to get fast feedback from failing unit tests is useful. And if you could easily identify the parts of your code that you still need to write tests for, you would get more comprehensive feedback. There is a plugin for Grunt that can use the JSCoverage tool to produce a coverage report while . . . → Read More: No line of your JavaScript code uncovered Being able to check the quality of your code and run all unit tests in your project on every commit is useful. If you could do it on every save you would get even faster feedback. Grunt includes a watch facility that will run a task every time some file is changed. You only need . . . → Read More: Check your JavaScript code on every save Being able to check the quality of your code on every commit is useful. But it would be even more useful if you could also run all your unit tests on every commit. Here I will show how you can extend the automated build setup to also run all your QUnit tests. (Switch to different . . . → Read More: Run all your JavaScript QUnit tests on every commit The previous post shows how to execute build steps from the command line. Usually this is all that is required for setting up a continuous integration server that will run those steps on every commit to your project. Since the sample code behind these blog posts is available on GitHub, you can easily set up . . . → Read More: Continuous Integration of your front-end JavaScript code using Travis-CI Update as of April 7, 2013: This blog series has now been extended with Jasmine and Istanbul. Update as of March 28, 2013: This blog series has now been upgraded to use Grunt-0.4. A lot of projects use continuous integration these days. It is still far more common for back-end projects using C#, Java or . . . → Read More: Automated build for your front-end JavaScript code A client of mine asked me this question today: One of our developers wants to write her BDD features using SpecFlow instead of our existing Cucumber JVM approach. Isn’t it a bad idea having two separate approaches? What are your thoughts on this. I think it is important that you constantly ask youself how you . . . → Read More: Tool Improvement Spikes If you are like most test driven developers, you write automated tests for your software to get fast feedback about potential problems. Most of the tests you write will verify the functional behaviour of the software: When we call this function or press this button, the expected result is that value or that message. But . . . → Read More: Automated Performance Testing Have you ever faced the problem of writing unit tests which relies on textual test data? This is a classic issue where you usually end up putting the test data in a string variable or in an external file, depending on the amount of text. Neither of these options are particularly elegant. In this article . . . → Read More: CommentReader – Place your test data next to the test code This week I gave a presentation for a client, starting on Test and Behavior Driven Development. In this introduction we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web . . . → Read More: Test and Behavior Driven Development (TDD/BDD) |
|||
|
Copyright © 2013 ZeaLake - All Rights Reserved |
