Testing

Testing

Definition:

The methodology known as test-driven development (TDD) substantially changes the way traditional software development is done. This methodology wants you to write tests even before writing the application code. Instead of just using testing to verify your work after it’s done, TDD moves testing into the earlier application design phase. You should use these tests to clarify your ideas about what you are about to program. Here is the fundamental mantra of TDD:

* Write a test and make it fail.
* Make the test pass.
* Refactor.
* Repeat.

This technique is also referred to as red-green-refactor because IDE's and test runners use red to indicate failed tests and green to indicate those that pass.

When you are about to start programming a class with business logic, ask yourself, "How can I ensure that this function works as expected?" After you know the answer, write a test JavaScript class that calls this function to assert that the business logic gives the expected result.

An assertion is a true-false statement that represents what a programmer assumes about program state. For example, customerID >0 is an assertion. According to Martin Fowler, assertion is a section of code that assumes something about the state of the program. Failure of an assertion results in test failure.

Run your test, and it will immediately fail because no application code is written yet! Only after the test is written, start programming the business logic of your application.

You should write the simplest possible piece of code to make the test pass. Don’t try to find a generic solution at this step. For example, if you want to test a calculator that needs to return 4 as result of 2 + 2, write code that simply returns 4. Don’t worry about the performance or optimization at this point. Just make the test pass. After you write it, you can refactor your application code to make it more efficient. Now you might want to introduce a real algorithm for implementing the application logic without worrying about breaking the contract with other components of your application.

A failed unit test indicates that your code change introduces regression, which is a new bug in previously working software. Automated testing and well-written test cases can reduce the likelihood of regression in your code.

TDD allows you to receive feedback from your code almost immediately. It’s better to find that something is broken during development rather than in an application deployed in production.

Learn by heart the Golden Rule of TDD:

Never write new functionality without a failing test.
In addition to business logic, web applications should be tested for proper rendering of UI components, changing view states, dispatching, and handling events.

With any testing framework, your tests will follow the same basic pattern. First, you need to set up the test environment. Second, you run the production code and check that it works as it is supposed to. Finally, you need to clean up after the test runs—remove everything that your program has created during setup of the environment.

This pattern for authoring unit tests is called arrange-act-assert-reset (AAAR).

* In the Arrange phase, you set up the unit of work to test. For example, create JavaScript objects and prepare dependencies.
* In the Act phase, you exercise the unit under test and capture the resulting state. You execute your production code in a unit-test context.
* In the Assert phase, you verify the behavior through assertions.
* In the Reset phase, you reset the environment to the initial state. For example, erase the DOM elements created in the Arrange phase. Most of the frameworks provide a "teardown" function that would be invoked after the test is done.


Is unit testing worth the effort: http://stackoverflow.com/questions/67299/is-unit-testing-worth-the-effort?rq=1