I am new to Unit testing but totally understand the benefits of it and want to start dong it more often.
I currently have a project that is already developed and id like to add tests to it.
It uses the revelaing module pattern with most of the methods as private is this a problem for testing?
Would i need to make them public or use one public method to call the private ones?
How do you choose what to test?
I assume that if it is a simple ajax call then you can test the responce etc but what if it is code for an accordion, what would you test then?
Unit testing is only for public methods. If you want to ensure that private methods are doing what they need to as well, more extensive functional tests and integration tests would then be wanted.
You test everything you can. Adding tests on to an already existing project doesn’t tend to result in much success. It’s usually better to use that project as initial development code that helps you to learn what needs to be done, and to then start a new set of development code where you use tests to help drive what code needs to be written.
If it’s a simple ajax call, you can replace it with a simple object to simluate what would normally be done. Unit testing is not for ensuring that the code causes the web browser to behave properly. Unit testing is only testing the structure of your code itself. Integration testing with something such as Selenium is where more extensive tests come in to place.
An excellent video about this is Test Driving JavaScript - it’s well worth the watch. He has an example in there about testing that an element is focussed, and his approach is quite insightful.
If you want to install the Ruby script that he uses to run JavaScript unit tests after a file save, I can supply further details about that too.
//--- CODE --------------------------
function requestHandler() {
}
function requestData(url, handler) {
$.get(url, handler);
}
//--- SPECS -------------------------
describe("usesJqueryAjaxRequest", function () {
it("callsJqueryGetMethod", function () {
spyOn($, 'get');
requestData();
expect($.get).toHaveBeenCalled();
});
it("callsDataPage", function () {
var url = 'getData.php';
spyOn($, 'get');
requestData(url);
expect($.get).toHaveBeenCalledWith(url, undefined);
});
// There are two ways of checking that functions have been called one is to make them public and use Spies to check on them, and the other is to pass it in as a dependency.
// The first option is what we'll use here.
it("handlesResponseFromUrl", function () {
var url = 'getData.php',
callback = requestHandler;
spyOn($, 'get');
requestData(url, callback);
expect($.get).toHaveBeenCalledWith(url, callback);
});
});
But, the code and the tests don’t tell the whole story. It’s a process of doing one test to define what is needed, then writing a minimum of code to achieve that test.
It’s a continuous cycle of:
[list][]Write a failing test
[]Pass the test
[*]Refactor
[/list]
It’s important to first have a failing test. If it doesn’t fail - is cannot determine if the code is doing what’s required.
Those tests above were used to build up the code, but because their asserts would all work from the last test, it would be a good idea to refactor the test to remove all but the last test - because that’s all that’s needed to test the existing functionality of the requestData function.
Yes, I read that. Basically you throw in special test code that gets stripped out production phase?
I still maintain though that unit tests are for defining the interface of your code. How the code achieves those results is not in the realm of unit testing. The following article gives some good details on the differences between unit, functional, acceptance, and integration testing,
if you were setting up a project yu knew you were going to be running both unit tests and functional tests what pattern would you follow for you js code?
The pattern that I would use is to not write code until I first have a failing test.
[list][]Write a simple failing test. If it doesn’t fail, it cannot verify that step 2 did anything.
[]Write just enough code for the test to pass. No more, otherwise you will end up with code that has no test to ensure that it properly works.
[*]Refactor your code. Make the code simpler so that it does the same job and continues to pass all the tests. Refactor the tests to remove duplication or multiple tests that check for the same things.[/list]
Then start with a new test.
The fail/pass/refactor paradigm is the heartbeat of a strong and capable system.
When you have enough tests and enough code that gives you something that can be used, that is where functional tests come in. Unit tests build up the interface for your code, checks that the code is structured in a way that is easy to test, and ensures that future changes you make (with a test first) don’t break your existing tests. Functional tests ensure that the code works properly in its environment.
You can see a good example of someone doing unit tests at [calculator TDD Kata in JavaScript](calculator tdd kata in javascript). You should notice in it that some parts have tests written for them, and other parts don’t have tests written for them. Is that because he’s getting ahead of himself and not doing the tests? Perhaps - or it could just mean that he needs to push some of the public methods down as private ones instead.
At around the 16 minute mark, you’ll see that he uses a try/catch to test for an exception. If you’re using Jasmine to do the testing, that has a test that can actually check if an exception has been thrown, such as:
ok so if i wrote a test that tested a value was being set for an item then i built the project and i had a function that had this code in what would be the best way to write that set of code so that i can test it? or are tests simply seperate and dont tests the functions themselves?
