Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:58:32Z

Sngala: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:58:05Z

Sngala: /* Adapter Pattern */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class ' WebSocket ' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class ' WebSocket ' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class ' WebSocket ', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:57:29Z

Sngala: /* Adaptor Pattern */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class ' WebSocket ' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using " Adapter Pattern " to convert the interface of class ' WebSocket ' into another interface that the caller expects. " Adapter pattern " allows other classes with incompatible interfaces to work together with class ' WebSocket ', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:46:55Z

Sngala: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class ' WebSocket ' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adaptor Pattern ===
We are using "Adaptor Pattern" to convert the interface of class ' WebSocket ' into another interface that the caller expects. Adaptor pattern allows other classes with incompatible interfaces to work together with class ' WebSocket ', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:44:34Z

Sngala: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adaptor Pattern ===
We are using "Adaptor Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. Adaptor pattern allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:40:42Z

Sngala: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

'''Singleton Pattern'''

We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

'''Adaptor Pattern'''

We are using "Adaptor Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. Using adaptor pattern allows other classes with incompatible interfaces work together with class 'WebSocket'.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:40:17Z

Sngala: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

'''Singleton Pattern'''
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

'''Adaptor Pattern'''
We are using "Adaptor Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. Using adaptor pattern allows other classes with incompatible interfaces work together with class 'WebSocket'.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T22:39:19Z

Sngala: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
<br>

2. Then we had to build the rust compiler.
<br>

3. To build the servo, we cloned the source code into the local repository.
<br>

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
<br>

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
<br>

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
<br>

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
<br>

8. We added the websocket module that we created to the lib.rs file.
<br>

9. After making all the changes we build are changes into servo.
<br>

10. This was Part One of our project, which was a part of our OSS project.
<br>

11. Part Two is our final project and is an extension of our OSS project.
<br>

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
<br>

14. We have to implement closing of connection along with on open and inclose events.
<br>

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adaptor Pattern ===
We are using "Adaptor Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. Using adaptor pattern allows other classes with incompatible interfaces work together with class 'WebSocket'.

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T19:17:04Z

Sngala: /* Servo */

= Integrating an XML Parser =

__TOC__

= Background Information =
Servo is an experimental web browser layout engine being developed by Mozilla Research. The prototype seeks to create a highly parallel environment, in which many components (such as rendering, layout, HTML parsing, image decoding, etc.) are handled by fine-grained, isolated tasks. The project has a symbiotic relationship with the Rust programming language, in which it is being developed.

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.
It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

== Servo ==
[https://github.com/servo/servo Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, Mozilla are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref name=Rust></ref>

''Task Supervision Diagram''

[[File:Diagram1.jpg]]

''Task Projection Diagram''

[[File:Diagram2.jpg]]

• '' Each box '' represents a Rust task.

• '' Blue boxes '' represent the primary tasks in the browser pipeline.

• '' Gray boxes '' represent tasks auxiliary to the browser pipeline.

• '' White boxes '' represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.

• '' Dashed lines '' indicate supervisor relationships.

• '' Solid lines '' indicate communication channels.

= Prerequisites =
'''Installing Dependencies for Servo'''

The list of commands to install the dependencies on various platforms are<ref name = github>[https://github.com/servo/servo Servo Github]</ref>

On OS X (homebrew):

brew install automake pkg-config python glfw3 cmake
pip install virtualenv

On OS X (MacPorts):

sudo port install python27 py27-virtualenv cmake

On Debian-based Linuxes:

sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev

On Fedora:

sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd

On Arch Linux:

sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake

'''Building Servo'''

''Normal Build''

git clone https://github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html

''Building for Android target''

git clone https://github.com/servo/servo
cd servo
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install

= Steps of Implementation =

→ Created a new file mod.rs in the following directory: <code> servo/components/script/parse/mod.rs</code>

→ Created a Parser Trait with the parse_chunk method in this mod.rs

pub mod html;
pub trait Parser {
fn parse_chunk(&self,input: String);
fn finish(&self);
}

→ Implementation of this Parser trait for the ServoHTML Parser struct is in the servo <code>/components/script/dom/servohtmlparser.rs</code>

impl Parser for ServoHTMLParser{
fn parse_chunk(&self, input: String) {
self.tokenizer().borrow_mut().feed(input);
}
fn finish(&self){
self.tokenizer().borrow_mut().end();
}
}

→ Modified <code>servo/components/script/parse/html.rs</code> to invoke the parse_chunk method appropriately.

InputString(s) => {
parser.parse_chunk(s);
}

InputUrl(url) => {
let load_response = load_response.unwrap();
match load_response.metadata.content_type {
Some((ref t, _)) if t.as_slice().eq_ignore_ascii_case("image") => {
let page = format!("<html><body><img src='{:s}' /></body></html>", base_url.as_ref().unwrap().serialize());
parser.parse_chunk(page);
},

Payload(data) => {
// FIXME: use Vec<u8> (html5ever #34)
let data = UTF_8.decode(data.as_slice(), DecodeReplace).unwrap();
parser.parse_chunk(data);
}

= Design Patterns =
We have followed “Programming to Interfaces, not an implementation” design principle while implementing initial step of our project. We have modified the code of html.rs to invoke Parser trait’s parse_chunk method instead of directly invoking instead of directly invoking the methods of ServoHtmlParser .Thereby in future , if in case we use any other parser instance instead of ServoHtmlParser , we need not modify the invocation logic in html.rs function.(Traits are similar to interfaces in other languages).

= References =
<references></references>

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T19:16:44Z

Sngala: /* Servo */

= Integrating an XML Parser =

__TOC__

= Background Information =
Servo is an experimental web browser layout engine being developed by Mozilla Research. The prototype seeks to create a highly parallel environment, in which many components (such as rendering, layout, HTML parsing, image decoding, etc.) are handled by fine-grained, isolated tasks. The project has a symbiotic relationship with the Rust programming language, in which it is being developed.

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.
It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

== Servo ==
[https://github.com/servo/servo Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, Mozilla are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref name=Rust></ref>

''Task Supervision Diagram''

[[File:Diagram1.jpg]]

''Task Projection Diagram''

[[File:Diagram2.jpg]]

• '' Each box '' represents a Rust task.

• '' Blue boxes '' represent the primary tasks in the browser pipeline.
• '' Gray boxes '' represent tasks auxiliary to the browser pipeline.
• '' White boxes '' represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
• '' Dashed lines '' indicate supervisor relationships.
• '' Solid lines '' indicate communication channels.

= Prerequisites =
'''Installing Dependencies for Servo'''

The list of commands to install the dependencies on various platforms are<ref name = github>[https://github.com/servo/servo Servo Github]</ref>

On OS X (homebrew):

brew install automake pkg-config python glfw3 cmake
pip install virtualenv

On OS X (MacPorts):

sudo port install python27 py27-virtualenv cmake

On Debian-based Linuxes:

sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev

On Fedora:

sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd

On Arch Linux:

sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake

'''Building Servo'''

''Normal Build''

git clone https://github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html

''Building for Android target''

git clone https://github.com/servo/servo
cd servo
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install

= Steps of Implementation =

→ Created a new file mod.rs in the following directory: <code> servo/components/script/parse/mod.rs</code>

→ Created a Parser Trait with the parse_chunk method in this mod.rs

pub mod html;
pub trait Parser {
fn parse_chunk(&self,input: String);
fn finish(&self);
}

→ Implementation of this Parser trait for the ServoHTML Parser struct is in the servo <code>/components/script/dom/servohtmlparser.rs</code>

impl Parser for ServoHTMLParser{
fn parse_chunk(&self, input: String) {
self.tokenizer().borrow_mut().feed(input);
}
fn finish(&self){
self.tokenizer().borrow_mut().end();
}
}

→ Modified <code>servo/components/script/parse/html.rs</code> to invoke the parse_chunk method appropriately.

InputString(s) => {
parser.parse_chunk(s);
}

InputUrl(url) => {
let load_response = load_response.unwrap();
match load_response.metadata.content_type {
Some((ref t, _)) if t.as_slice().eq_ignore_ascii_case("image") => {
let page = format!("<html><body><img src='{:s}' /></body></html>", base_url.as_ref().unwrap().serialize());
parser.parse_chunk(page);
},

Payload(data) => {
// FIXME: use Vec<u8> (html5ever #34)
let data = UTF_8.decode(data.as_slice(), DecodeReplace).unwrap();
parser.parse_chunk(data);
}

= Design Patterns =
We have followed “Programming to Interfaces, not an implementation” design principle while implementing initial step of our project. We have modified the code of html.rs to invoke Parser trait’s parse_chunk method instead of directly invoking instead of directly invoking the methods of ServoHtmlParser .Thereby in future , if in case we use any other parser instance instead of ServoHtmlParser , we need not modify the invocation logic in html.rs function.(Traits are similar to interfaces in other languages).

= References =
<references></references>

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T19:15:13Z

Sngala:

= Integrating an XML Parser =

__TOC__

= Background Information =
Servo is an experimental web browser layout engine being developed by Mozilla Research. The prototype seeks to create a highly parallel environment, in which many components (such as rendering, layout, HTML parsing, image decoding, etc.) are handled by fine-grained, isolated tasks. The project has a symbiotic relationship with the Rust programming language, in which it is being developed.

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.
It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

== Servo ==
[https://github.com/servo/servo Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, Mozilla are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref name=Rust></ref>

''Task Supervision Diagram''

[[File:Diagram1.jpg]]

''Task Projection Diagram''

[[File:Diagram2.jpg]]

• Each box represents a Rust task.
• Blue boxes represent the primary tasks in the browser pipeline.
• Gray boxes represent tasks auxiliary to the browser pipeline.
• White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
• Dashed lines indicate supervisor relationships.
• Solid lines indicate communication channels.

= Prerequisites =
'''Installing Dependencies for Servo'''

The list of commands to install the dependencies on various platforms are<ref name = github>[https://github.com/servo/servo Servo Github]</ref>

On OS X (homebrew):

brew install automake pkg-config python glfw3 cmake
pip install virtualenv

On OS X (MacPorts):

sudo port install python27 py27-virtualenv cmake

On Debian-based Linuxes:

sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev

On Fedora:

sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd

On Arch Linux:

sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake

'''Building Servo'''

''Normal Build''

git clone https://github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html

''Building for Android target''

git clone https://github.com/servo/servo
cd servo
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install

= Steps of Implementation =

→ Created a new file mod.rs in the following directory: <code> servo/components/script/parse/mod.rs</code>

→ Created a Parser Trait with the parse_chunk method in this mod.rs

pub mod html;
pub trait Parser {
fn parse_chunk(&self,input: String);
fn finish(&self);
}

→ Implementation of this Parser trait for the ServoHTML Parser struct is in the servo <code>/components/script/dom/servohtmlparser.rs</code>

impl Parser for ServoHTMLParser{
fn parse_chunk(&self, input: String) {
self.tokenizer().borrow_mut().feed(input);
}
fn finish(&self){
self.tokenizer().borrow_mut().end();
}
}

→ Modified <code>servo/components/script/parse/html.rs</code> to invoke the parse_chunk method appropriately.

InputString(s) => {
parser.parse_chunk(s);
}

InputUrl(url) => {
let load_response = load_response.unwrap();
match load_response.metadata.content_type {
Some((ref t, _)) if t.as_slice().eq_ignore_ascii_case("image") => {
let page = format!("<html><body><img src='{:s}' /></body></html>", base_url.as_ref().unwrap().serialize());
parser.parse_chunk(page);
},

Payload(data) => {
// FIXME: use Vec<u8> (html5ever #34)
let data = UTF_8.decode(data.as_slice(), DecodeReplace).unwrap();
parser.parse_chunk(data);
}

= Design Patterns =
We have followed “Programming to Interfaces, not an implementation” design principle while implementing initial step of our project. We have modified the code of html.rs to invoke Parser trait’s parse_chunk method instead of directly invoking instead of directly invoking the methods of ServoHtmlParser .Thereby in future , if in case we use any other parser instance instead of ServoHtmlParser , we need not modify the invocation logic in html.rs function.(Traits are similar to interfaces in other languages).

= References =
<references></references>

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T18:53:02Z

Sngala: /* Design Patterns */

= Integrating an XML Parser =

__TOC__

= Background Information =
Servo is an experimental web browser layout engine being developed by Mozilla Research. The prototype seeks to create a highly parallel environment, in which many components (such as rendering, layout, HTML parsing, image decoding, etc.) are handled by fine-grained, isolated tasks. The project has a symbiotic relationship with the Rust programming language, in which it is being developed.

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.
It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

== Servo ==
[https://github.com/servo/servo Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, Mozilla are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref name=Rust></ref>

= Prerequisites =
'''Installing Dependencies for Servo'''

The list of commands to install the dependencies on various platforms are<ref name = github>[https://github.com/servo/servo Servo Github]</ref>

On OS X (homebrew):

brew install automake pkg-config python glfw3 cmake
pip install virtualenv

On OS X (MacPorts):

sudo port install python27 py27-virtualenv cmake

On Debian-based Linuxes:

sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev

On Fedora:

sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd

On Arch Linux:

sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake

'''Building Servo'''

''Normal Build''

git clone https://github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html

''Building for Android target''

git clone https://github.com/servo/servo
cd servo
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install

= Steps of Implementation =

→ Created a new file mod.rs in the following directory: <code> servo/components/script/parse/mod.rs</code>

→ Created a Parser Trait with the parse_chunk method in this mod.rs

pub mod html;
pub trait Parser {
fn parse_chunk(&self,input: String);
fn finish(&self);
}

→ Implementation of this Parser trait for the ServoHTML Parser struct is in the servo <code>/components/script/dom/servohtmlparser.rs</code>

impl Parser for ServoHTMLParser{
fn parse_chunk(&self, input: String) {
self.tokenizer().borrow_mut().feed(input);
}
fn finish(&self){
self.tokenizer().borrow_mut().end();
}
}

→ Modified <code>servo/components/script/parse/html.rs</code> to invoke the parse_chunk method appropriately.

InputString(s) => {
parser.parse_chunk(s);
}

InputUrl(url) => {
let load_response = load_response.unwrap();
match load_response.metadata.content_type {
Some((ref t, _)) if t.as_slice().eq_ignore_ascii_case("image") => {
let page = format!("<html><body><img src='{:s}' /></body></html>", base_url.as_ref().unwrap().serialize());
parser.parse_chunk(page);
},

Payload(data) => {
// FIXME: use Vec<u8> (html5ever #34)
let data = UTF_8.decode(data.as_slice(), DecodeReplace).unwrap();
parser.parse_chunk(data);
}

= Design Patterns =
We have followed “Programming to Interfaces, not an implementation” design principle while implementing initial step of our project. We have modified the code of html.rs to invoke Parser trait’s parse_chunk method instead of directly invoking instead of directly invoking the methods of ServoHtmlParser .Thereby in future , if in case we use any other parser instance instead of ServoHtmlParser , we need not modify the invocation logic in html.rs function.(Traits are similar to interfaces in other languages).

= References =
<references></references>

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T18:49:17Z

Sngala: /* Steps of Implementation */

= Integrating an XML Parser =

__TOC__

= Background Information =
Servo is an experimental web browser layout engine being developed by Mozilla Research. The prototype seeks to create a highly parallel environment, in which many components (such as rendering, layout, HTML parsing, image decoding, etc.) are handled by fine-grained, isolated tasks. The project has a symbiotic relationship with the Rust programming language, in which it is being developed.

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.
It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. <ref name=Rust>[https://www.mozilla.org/en-US/research/projects/ Overview of Mozilla Research Projects]</ref>

== Servo ==
[https://github.com/servo/servo Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, Mozilla are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.<ref name=Rust></ref>

= Prerequisites =
'''Installing Dependencies for Servo'''

The list of commands to install the dependencies on various platforms are<ref name = github>[https://github.com/servo/servo Servo Github]</ref>

On OS X (homebrew):

brew install automake pkg-config python glfw3 cmake
pip install virtualenv

On OS X (MacPorts):

sudo port install python27 py27-virtualenv cmake

On Debian-based Linuxes:

sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev

On Fedora:

sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd

On Arch Linux:

sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake

'''Building Servo'''

''Normal Build''

git clone https://github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html

''Building for Android target''

git clone https://github.com/servo/servo
cd servo
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install

= Steps of Implementation =

→ Created a new file mod.rs in the following directory: <code> servo/components/script/parse/mod.rs</code>

→ Created a Parser Trait with the parse_chunk method in this mod.rs

pub mod html;
pub trait Parser {
fn parse_chunk(&self,input: String);
fn finish(&self);
}

→ Implementation of this Parser trait for the ServoHTML Parser struct is in the servo <code>/components/script/dom/servohtmlparser.rs</code>

impl Parser for ServoHTMLParser{
fn parse_chunk(&self, input: String) {
self.tokenizer().borrow_mut().feed(input);
}
fn finish(&self){
self.tokenizer().borrow_mut().end();
}
}

→ Modified <code>servo/components/script/parse/html.rs</code> to invoke the parse_chunk method appropriately.

InputString(s) => {
parser.parse_chunk(s);
}

InputUrl(url) => {
let load_response = load_response.unwrap();
match load_response.metadata.content_type {
Some((ref t, _)) if t.as_slice().eq_ignore_ascii_case("image") => {
let page = format!("<html><body><img src='{:s}' /></body></html>", base_url.as_ref().unwrap().serialize());
parser.parse_chunk(page);
},

Payload(data) => {
// FIXME: use Vec<u8> (html5ever #34)
let data = UTF_8.decode(data.as_slice(), DecodeReplace).unwrap();
parser.parse_chunk(data);
}

= Design Patterns =
We have followed “Programming to Interfaces, not an implementation” design principle while implementing initial step of our project. We have modified the code of html.rs to invoke Parser trait’s parse_chunk method instead of directly invoking instead of directly invoking the methods of ServoHtmlParser .Thereby in future , if in case we use any other parser instance instead of ServoHtmlParser , we need not modify the invocation logic in html.rs function.(Traits are similar to interfaces in other languages).

We are planning to use parameterized variation of factory method design pattern to create instances of either html parser or Xml parser based on the HTTP Content-Type header. In html.rs file, instead of directly creating instances of ServoHtmlParser(like ServoHtmlParser::new..) ,we would be calling a function like build_parser by passing in HTTP Content-Type header as parameter. This build_parser method will return either instance of ServoHtmlParser or XML Parser based on the content type parameter. Here, build_parser will be acting as factory method .

= References =
<references></references>

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T17:39:16Z

Sngala:

= Integrating an XML Parser =
This wiki is about the project M 1452: Integrate an XML Parser, which is a part of the ongoing development on the Servo browser. Below you can find a brief description about the servo project, rust programming language, requirements of this particular project, setting up of the development environment and other relevant details.

__TOC__
= Background Information =

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.

== Servo ==

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T17:30:09Z

Sngala:

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T17:27:28Z

Sngala:

= Integrating an XML Parser =
This wiki is about the project M 1452: Integrate an XML Parser, which is a part of the ongoing development on the Servo browser. Below you can find a brief description about the servo project, rust programming language, requirements of this particular project, setting up of the development environment and other relevant details.

= Background Information =

== Rust ==
[http://www.rust-lang.org/ Rust] is a systems language for writing high performance applications that are usually written in C or C++ but it was developed to prevent some of the problems related to invalid memory accesses that generate segmentation faults. It covers imperative, functional and object-oriented programming.

CSC/ECE 517 Fall 2014/oss M1452 jns

2014-10-27T15:32:36Z

Sngala: Created page with "= Integrating an XML Parser = This wiki is about the project M 1452: Integrate an XML Parser, which is a part of the ongoing development on the Servo browser. Below you can find ..."

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-14T03:00:38Z

Sngala: /* Drawbacks */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the [http://en.wikipedia.org/wiki/Document_Object_Model DOM] or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many frameworks don't support testing asynchronous code like event callbacks.
* Some frameworks have syntax that is hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
[http://en.wikipedia.org/wiki/Test_suite Test suites] are generally used to group similar test cases together. In Jasmine a test suite begins with a call to the global function <code>describe</code> with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function <code>it</code>, which, like <code>describe</code> takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the <code>xdescribe</code> and <code>xit</code> functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function <code>expect</code> which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec. Any matcher can evaluate to a negative assertion by chaining the call to <code>expect</code> with a <code>not</code> before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*<code>toBe</code>: represents the exact equality (===) operator.
*<code>toEqual</code>: represents the regular equality (==) operator.
*<code>toMatch</code>: calls the RegExp match() method behind the scenes to compare string data.
*<code>toBeDefined</code>: opposite of the JS "undefined" constant.
*<code>toBeUndefined</code>: tests the actual against "undefined".
*<code>toBeNull</code>: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*<code>toBeTruthy</code>: simulates JavaScript boolean casting.
*<code>toBeFalsy</code>: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*<code>toContain</code>: performs a search on an array for the actual value.
*<code>toBeLessThan</code>/<code>toBeGreaterThan</code>: for numerical comparisons.
*<code>toBeCloseTo</code>: for floating point comparisons.
*<code>toThrow</code>: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The <code>describe</code> function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite [http://en.wikipedia.org/wiki/Don't_repeat_yourself DRY] up any duplicated setup and teardown code, Jasmine provides the global <code>beforeEach</code> and <code>afterEach</code> functions. As the name implies the <code>beforeEach</code> function is called once before each spec in the describe is run and the <code>afterEach</code> function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
In Jasmine, test doubles are called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the <code>describe</code> or <code>it</code> block it is defined in, and is removed after each spec.
There are special matchers for interacting with spies.
The <code>toHaveBeenCalled</code> matcher returns true if the spy is called. The <code>toHaveBeenCalledWith</code> matcher returns true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions <code>runs</code> and <code>waitsFor</code>:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*<code>runs</code> – takes the asynchronous function for execution;
*<code>waitsFor</code> – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code. It is installed with a call to <code>jasmine.clock().install</code> in a spec or suite that needs to manipulate time. The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like <code>setTimeout</code> or <code>setInterval</code> can be made synchronous executing the registered functions only once the clock is ticked forward in time. To execute registered functions, move time forward via the <code>jasmine.clock().tick</code> function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to <code>mockDate</code> it will use the current date.<ref name="New Features"/>

The following example demonstrates usage of jasmine Clock.

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
<code>jasmine.any</code> takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between three popular JavaScript test frameworks - Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node.
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI server] support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred for asynchronous testing, better flexibility and better usability.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-14T03:00:22Z

Sngala: /* Drawbacks */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the [http://en.wikipedia.org/wiki/Document_Object_Model DOM] or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many frameworks don't support testing asynchronous code like event callbacks.
* Some frameworks have syntax that is hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
[http://en.wikipedia.org/wiki/Test_suite Test suites] are generally used to group similar test cases together. In Jasmine a test suite begins with a call to the global function <code>describe</code> with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function <code>it</code>, which, like <code>describe</code> takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the <code>xdescribe</code> and <code>xit</code> functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function <code>expect</code> which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec. Any matcher can evaluate to a negative assertion by chaining the call to <code>expect</code> with a <code>not</code> before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*<code>toBe</code>: represents the exact equality (===) operator.
*<code>toEqual</code>: represents the regular equality (==) operator.
*<code>toMatch</code>: calls the RegExp match() method behind the scenes to compare string data.
*<code>toBeDefined</code>: opposite of the JS "undefined" constant.
*<code>toBeUndefined</code>: tests the actual against "undefined".
*<code>toBeNull</code>: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*<code>toBeTruthy</code>: simulates JavaScript boolean casting.
*<code>toBeFalsy</code>: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*<code>toContain</code>: performs a search on an array for the actual value.
*<code>toBeLessThan</code>/<code>toBeGreaterThan</code>: for numerical comparisons.
*<code>toBeCloseTo</code>: for floating point comparisons.
*<code>toThrow</code>: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The <code>describe</code> function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite [http://en.wikipedia.org/wiki/Don't_repeat_yourself DRY] up any duplicated setup and teardown code, Jasmine provides the global <code>beforeEach</code> and <code>afterEach</code> functions. As the name implies the <code>beforeEach</code> function is called once before each spec in the describe is run and the <code>afterEach</code> function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
In Jasmine, test doubles are called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the <code>describe</code> or <code>it</code> block it is defined in, and is removed after each spec.
There are special matchers for interacting with spies.
The <code>toHaveBeenCalled</code> matcher returns true if the spy is called. The <code>toHaveBeenCalledWith</code> matcher returns true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions <code>runs</code> and <code>waitsFor</code>:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*<code>runs</code> – takes the asynchronous function for execution;
*<code>waitsFor</code> – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code. It is installed with a call to <code>jasmine.clock().install</code> in a spec or suite that needs to manipulate time. The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like <code>setTimeout</code> or <code>setInterval</code> can be made synchronous executing the registered functions only once the clock is ticked forward in time. To execute registered functions, move time forward via the <code>jasmine.clock().tick</code> function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to <code>mockDate</code> it will use the current date.<ref name="New Features"/>

The following example demonstrates usage of jasmine Clock.

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
<code>jasmine.any</code> takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between three popular JavaScript test frameworks - Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node.
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI server] support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred for asynchronous testing,better flexibility and better usability.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:31:41Z

Sngala: /* Comparison between Jasmine, Qunit and Mocha */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node.
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI server] support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred for asynchronous testing,better flexibility and better usability.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:27:19Z

Sngala: /* Suites */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node.
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI servers] server support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred for asynchronous testing,better flexibility and better usability.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:23:38Z

Sngala: /* Drawbacks */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node.
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI servers] server support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred for asynchronous testing,better flexibility and better usability.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:21:21Z

Sngala: /* Comparison between Jasmine, Qunit and Mocha */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node.
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI servers] server support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* For asynchronous testing,more flexibility and usability [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:19:09Z

Sngala:

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI servers] server support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* For asynchronous testing,more flexibility and usability [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:18:35Z

Sngala: /* Comparison between Jasmine, Qunit and Mocha */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI servers] server support.</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained.
*Including assertion libraries is difficult.

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others.
*Has aliases for functions to be more BDD-oriented or TDD-oriented.
*Highly extensible.
*Asynchronous testing is easy.</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* For asynchronous testing,more flexibility and usability [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>
=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:17:14Z

Sngala: /* Comparison between Jasmine, Qunit and Mocha */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI servers] ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI servers] server support</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained
*Including 3rd party libraries (like assertion libraries) is difficult

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others (jenkins has a maven plugin)
*Has aliases for functions to be more BDD-oriented or TDD-oriented
*Highly extensible
*Asynchronous testing is easy</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* For asynchronous testing,more flexibility and usability [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>
=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:16:45Z

Sngala: /* Comparison between Jasmine, Qunit and Mocha */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many [http://en.wikipedia.org/wiki/Continuous_integration CI] servers ([https://www.jetbrains.com/teamcity/ TeamCity], [https://www.codeship.io/ Codeship], etc.)
*Descriptive syntax for BDD paradigm</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files.</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to [http://en.wikipedia.org/wiki/Continuous_integration CI] server support</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained
*Including 3rd party libraries (like assertion libraries) is difficult

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others (jenkins has a maven plugin)
*Has aliases for functions to be more BDD-oriented or TDD-oriented
*Highly extensible
*Asynchronous testing is easy</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* For asynchronous testing,more flexibility and usability [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>
=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T20:06:27Z

Sngala:

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

=Comparison between Jasmine, Qunit and Mocha=
The following gives a difference between Jasmine, Qunit and Mocha.<ref name="Comparison">https://github.com/thegrtman/javascript-test-framework-comparison</ref>
<table border="2">
<tr>
<th> Frameworks </th>
<th> Pros </th>
<th> Cons </th>
</tr>
<tr>
<td> [http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] </td>
<td>
*Simple setup for node through jasmine-node
*Fluent syntax for assertions built-in, and works well with other assertion libraries
*Supported by many CI servers (TeamCity, Codeship, etc.) and some that don't support natively have plugins (jenkins has a maven plugin)
*Descriptive syntax for BDD paradigm</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Expects a specific suffix to all test files (*spec.js by default)</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/QUnit Qunit]</td>
<td>
*Lots of support across the board, from Q&A to CI server support</td>
<td>
*Asynchronous testing causes a lot of difficulties.
*Configuration is really difficult, and must constantly be maintained
*Including 3rd party libraries (like assertion libraries) is difficult

</td>
</tr>
<tr>
<td>[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]</td>
<td>
*Simple setup
*Supported by some CI servers and plugins for others (jenkins has a maven plugin)
*Has aliases for functions to be more BDD-oriented or TDD-oriented
*Highly extensible
*Asynchronous testing is easy</td>
<td>
*It's relatively new so support might be lacking in certain areas.

</td>
</tr>
</table>
= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>
* For asynchronous testing,more flexibility and usability [http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha] is preferred.<ref name="difference">http://www.techtalkdc.com/which-javascript-test-library-should-you-use-qunit-vs-jasmine-vs-mocha/</ref>
=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]
*[http://en.wikipedia.org/wiki/Mocha_(JavaScript_framework) Mocha]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T19:28:23Z

Sngala:

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* It shouldn't be tied to any browser, framework, platform, or host language.
* It should have idiomatic and unsurprising syntax.
* It should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* It shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* It should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T19:22:09Z

Sngala: /* Goals */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* Shouldn't be tied to any browser, framework, platform, or host language.
* Should have idiomatic and unsurprising syntax.
* Should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* Shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* Should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* It should encourage good testing practices.
* It should integrate easily with continuous build systems.
* It should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T19:21:52Z

Sngala: /* Design Principles */

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* Shouldn't be tied to any browser, framework, platform, or host language.
* Should have idiomatic and unsurprising syntax.
* Should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* Shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* Should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T19:20:01Z

Sngala:

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

Jasmine is often used in the [http://en.wikipedia.org/wiki/Ruby_on_Rails Rails framework]. Jasmine is available as a [http://en.wikipedia.org/wiki/RubyGems Rubygem] and it automates common workflows by leveraging known rake tasks and generators. Jasmine is highly influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

=See Also=
*[http://en.wikipedia.org/wiki/JavaScript Javascript]
*[http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)]
*[http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)]
*[http://rspec.info/ RSpec]
*[http://en.wikipedia.org/wiki/QUnit Qunit]

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-13T18:59:49Z

Sngala:

'''Jasmine'''

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the [http://en.wikipedia.org/wiki/MIT_License MIT license]. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in an application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If they are named well, specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.The clock needs to be uninstalled after the original functions are restored.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
Functions like setTimeout or setInterval can be made synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If not provided with a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with [http://en.wikipedia.org/wiki/Test-driven_development Test Driven Development (TDD)].
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

Generally TDD suggests writing unit tests at the beginning of the application development process to help the developer design the code. This helps the developer design the object and method interfaces through test, and refactor the code and tests as the code matures. These tests are often written as a white box test-inside-out that test the specific implementation of a piece of code.
BDD also emphasizes writing unit tests, but instead of focusing on the inside-out test approach, it approaches the test from a business value perspective which tests outside-in.
BDD emphasizes that test authors focus on why a piece of code is necessary, and what its goal is. <ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>

This approach is adopted in the way all tests are written in Jasmine. In Jasmine each test describes the behavior of the unit under test, through an "it should do the following" kind of clause.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe"/>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-07T20:30:16Z

Sngala:

'''Jasmine'''

[http://jasmine.github.io/ Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the MIT license. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-07T20:29:01Z

Sngala:

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-06T18:36:40Z

Sngala:

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for [http://en.wikipedia.org/wiki/JavaScript JavaScript]. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the MIT license. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with Test Driven Development (TDD).
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

In Jasmine each test describes he behavior of the unit under test.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-06T18:35:53Z

Sngala:

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source [http://en.wikipedia.org/wiki/Behavior-driven_development Behavior Driven Development (BDD)] based testing framework for JavaScript. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the MIT license. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with Test Driven Development (TDD).
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

In Jasmine each test describes he behavior of the unit under test.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-06T18:34:37Z

Sngala:

[http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework) Jasmine] is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. It is maintained by [http://pivotallabs.com/ Pivotal Labs] and is available on [http://en.wikipedia.org/wiki/GitHub GitHub] under the MIT license. Jasmine allows tests to be written independent of the DOM or other JavaScript frameworks. Jasmine can be run in a browser, or headless without a browser by integrating with other frameworks such as [http://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) Rhino], Envy, or the Jasmine-headless-webkit library.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as [https://github.com/nkallen/screw-unit ScrewUnit], [https://code.google.com/p/jsspec/ JSSpec], [https://github.com/liblime/jspec JSpec], and [http://rspec.info/ RSpec]; and has syntax very similar to [http://rspec.info/ RSpec].

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

[http://behaviour-driven.org/ Behavior Driven Development] (abbreviated as BDD) is a software development process that was developed in response to issues encountered with Test Driven Development (TDD).
BDD is based on the techniques and principles of TDD, while combining these with ideas from domain-driven design and object-oriented analysis and design. BDD focuses on the behavioral specification of software units.

While TDD is quite non-specific about what should be tested and at what level of detail, BDD specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit.
BDD also specifies how the behavior should be specified. BDD uses a semi-formal format for behavioral specification which is borrowed from user story specifications from the field of object-oriented analysis and design.

In Jasmine each test describes he behavior of the unit under test.

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:30:17Z

Sngala: /* Drawbacks */

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the [http://en.wikipedia.org/wiki/JavaScript Javascript] code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like [http://en.wikipedia.org/wiki/Java_(programming_language) Java] and [http://en.wikipedia.org/wiki/PHP PHP].<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* [http://en.wikipedia.org/wiki/QUnit Qunit] is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:25:55Z

Sngala: /* Grouping Related Specs with describe */

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional [http://en.wikipedia.org/wiki/Behavior-driven_development BDD] style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the Javascript code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* Qunit is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like Java and PHP.<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* Qunit is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:24:38Z

Sngala: /* Usage */

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of [http://en.wikipedia.org/wiki/Behavior-driven_development behavior-driven development] and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the Javascript code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* Qunit is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like Java and PHP.<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* Qunit is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:23:01Z

Sngala: /* Usage */

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of [http://en.wikipedia.org/wiki/RSpec RSpec].<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the Javascript code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* Qunit is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like Java and PHP.<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* Qunit is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:21:15Z

Sngala: /* Background */

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for [http://en.wikipedia.org/wiki/JavaScript JS] developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good [http://en.wikipedia.org/wiki/JavaScript JavaScript]testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere [http://en.wikipedia.org/wiki/JavaScript JavaScript]can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of RSpec.<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the Javascript code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* Qunit is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like Java and PHP.<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* Qunit is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:10:21Z

Sngala: /* Drawbacks */

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for JS developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good JavaScript testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of RSpec.<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for integration testing, because Jasmine only tests the Javascript code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* Qunit is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like Java and PHP.<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* Qunit is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T23:09:32Z

Sngala:

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for JS developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good JavaScript testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of RSpec.<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =
* Jasmine is not recommended for your integration tests, because Jasmine only tests the Javascript code on one system at a time.<ref name="Adobe">http://www.adobe.com/devnet/html5/articles/unit-test-javascript-applications-with-jasmine.html</ref>
* Qunit is preferred more over Jasmine since it follow more similar conventions to other unit testing frameworks like Java and PHP.<ref name="Alternatives">http://tech.pro/q/39/what-javascript-testing-framework-do-you-prefer-and-why</ref>
* Qunit is simpler, easy for beginners and has a straight forward syntax hence its preferred over Jasmine.<ref name="Alternatives"/>

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T22:55:18Z

Sngala:

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for JS developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good JavaScript testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of RSpec.<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});
expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T22:53:59Z

Sngala:

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for JS developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good JavaScript testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of RSpec.<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

=== Matching Anything with jasmine.any ===
jasmine.any takes a constructor or “class” name as an expected value. It returns true if the constructor matches the constructor of the actual value.<ref name="New Features"/>

describe("jasmine.any", function() {
it("matches any value", function() {
expect({}).toEqual(jasmine.any(Object));
expect(12).toEqual(jasmine.any(Number));
});
describe("when used with a spy", function() {
it("is useful for comparing arguments", function() {
var foo = jasmine.createSpy('foo');
foo(12, function() {
return true;
});

expect(foo).toHaveBeenCalledWith(jasmine.any(Number), jasmine.any(Function));
});
});
});

= Behavior Driven Design =

= Drawbacks =

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T22:50:31Z

Sngala:

Jasmine is an open source Behavior Driven Development (BDD) based testing framework for JavaScript. Jasmine aims to run on any Javascript-enabled platform, to not intrude on the application nor the IDE, and to have easy-to-read syntax.

It can be used in the Rails framework. Jasmine ships as a Rubygem and leverages familiar rake tasks and generators to automate common workflows. Jasmine is heavily influenced by other unit testing frameworks, such as ScrewUnit, JSSpec, JSpec, and RSpec; and has syntax very similar to RSpec.

= Background =

The Jasmine framework was developed since developers to address certain specific concerns in existing testing frameworks <ref name="Background">https://github.com/pivotal/jasmine/wiki/Background</ref>
* Many frameworks only work from within a browser.
* Many don't support testing asynchronous code like event callbacks.
* Some have syntax that's hard for JS developers or IDEs to understand.

== Design Principles ==
The Jasmine developer community believes that a good JavaScript testing framework must follow these principles. <ref name="Background"/>
* should not be tied to any browser, framework, platform, or host language.
* should have idiomatic and unsurprising syntax.
* should work anywhere JavaScript can run, including browsers, servers, phones, etc.
* shouldn't intrude in your application's territory (e.g. by cluttering the global namespace).
* should play well with IDEs (e.g. test code should pass static analysis).

== Goals ==
The Jasmine framework is written with the objective of meeting these goals.<ref name="Background"/>
* it should encourage good testing practices.
* it should integrate easily with continuous build systems.
* it should be simple to get started with.

= Usage =
Jasmine aims to be easy to read. A simple hello world test looks like the code below, where describe() describes a suite of tests and it() is an individual test specification. The name "it()" follows the idea of behavior-driven development and serves as the first word in the test name, which should be a complete sentence. Usage follows syntax similar to that of RSpec.<ref name="Usage">http://en.wikipedia.org/wiki/Jasmine_(JavaScript_framework)</ref>

describe('Hello world', function() {
it('says hello', function() {
expect(helloWorld()).toEqual("Hello world!");
});
});

== Features ==

=== Suites ===
A test suite begins with a call to the global Jasmine function describe with two parameters: a string and a function. The string is a name or title for a spec suite – usually what is under test. The function is a block of code that implements the suite.<ref name="Features">http://jasmine.github.io/1.3/introduction.html</ref>

describe("A suite", function() {
it("contains spec with an expectation", function() {
expect(true).toBe(true);
});
});

=== Specs ===
Specs are defined by calling the global Jasmine function it, which, like describe takes a string and a function. The string is a title for this spec and the function is the spec, or test. A spec contains one or more expectations that test the state of the code under test.<ref name="Features"/>

An expectation in Jasmine is an assertion that can be either true or false. A spec with all true expectations is a passing spec. A spec with one or more expectations that evaluate to false is a failing spec.

describe("A suite is just a function", function() {
var a;
it("and so is a spec", function() {
a = true;
expect(a).toBe(true);
});
});

=== Disabling Specs and Suits ===
Suites and specs can be disabled with the xdescribe and xit functions, respectively. These suites and specs are skipped when run and thus their results will not appear in the results.<ref name="Features"/>

xdescribe("A spec", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
xit("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
});

=== Expectations ===
Expectations are built with the function expect which takes a value, called the actual. It is chained with a Matcher function, which takes the expected value.<ref name="Features"/>

==== Matchers ====
Each matcher implements a boolean comparison between the actual value and the expected value. It is responsible for reporting to Jasmine if the expectation is true or false. Jasmine will then pass or fail the spec.Any matcher can evaluate to a negative assertion by chaining the call to expect with a not before calling the matcher.<ref name="Features"/>

describe("The 'toBe' matcher compares with ===", function() {
it("and has a positive case ", function() {
expect(true).toBe(true);
});
it("and can have a negative case", function() {
expect(false).not.toBe(true);
});
});

==== Included Matchers ====
Jasmine has a rich set of matchers included. Some of them are listed below.<ref name="Included Matchers">http://www.htmlgoodies.com/beyond/javascript/testing-javascript-using-the-jasmine-framework.html</ref>
*toBe: represents the exact equality (===) operator.
*toEqual: represents the regular equality (==) operator.
*toMatch: calls the RegExp match() method behind the scenes to compare string data.
*toBeDefined: opposite of the JS "undefined" constant.
*toBeUndefined: tests the actual against "undefined".
*toBeNull: tests the actual against a null value - useful for certain functions that may return null, like those of regular expressions (same as toBe(null))
*toBeTruthy: simulates JavaScript boolean casting.
*toBeFalsy: like toBeTruthy, but tests against anything that evaluates to false, such as empty strings, zero, undefined, etc…
*toContain: performs a search on an array for the actual value.
*toBeLessThan/toBeGreaterThan: for numerical comparisons.
*toBeCloseTo: for floating point comparisons.
*toThrow: for catching expected exceptions.

There is also the ability to write [https://github.com/pivotal/jasmine/wiki/Matchers custom matchers]when a project’s domain calls for specific assertions that are not included.

=== Grouping Related Specs with describe ===
The describe function is for grouping related specs. The string parameter is for naming the collection of specs, and will be concatenated with specs to make a spec’s full name. This aids in finding specs in a large suite. If you name them well, your specs read as full sentences in traditional BDD style.<ref name="Features"/>

describe("A spec", function() {
it("is just a function, so it can contain any code", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
var foo = 0;
foo += 1;
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

==== Setup and Teardown ====
To help a test suite DRY up any duplicated setup and teardown code, Jasmine provides the global beforeEach and afterEach functions. As the name implies the beforeEach function is called once before each spec in the describe is run and the afterEach function is called once after each spec.<ref name="Features"/>

describe("A spec (with setup and tear-down)", function() {
var foo;
beforeEach(function() {
foo = 0;
foo += 1;
});
afterEach(function() {
foo = 0;
});
it("is just a function, so it can contain any code", function() {
expect(foo).toEqual(1);
});
it("can have more than one expectation", function() {
expect(foo).toEqual(1);
expect(true).toEqual(true);
});
});

=== Spies ===
Jasmine’s has test double functions called spies. A spy can stub any function and tracks calls to it and all arguments. A spy only exists in the describe or it block it is defined, and will be removed after each spec. There are special matchers for interacting with spies. The toHaveBeenCalled matcher will return true if the spy was called. The toHaveBeenCalledWith matcher will return true if the argument list matches any of the recorded calls to the spy.<ref name="New Features">http://jasmine.github.io/edge/introduction.html</ref>

describe("A spy", function() {
var foo, bar = null;
beforeEach(function() {
foo = {
setBar: function(value) {
bar = value;
}
};
spyOn(foo, 'setBar');
foo.setBar(123);
foo.setBar(456, 'another param');
});
it("tracks that the spy was called", function() {
expect(foo.setBar).toHaveBeenCalled();
});
it("tracks all the arguments of its calls", function() {
expect(foo.setBar).toHaveBeenCalledWith(123);
expect(foo.setBar).toHaveBeenCalledWith(456, 'another param');
});
it("stops all execution on a function", function() {
expect(bar).toBeNull();
});
});

=== Asynchronous Calls ===
Jasmine also supports testing of asynchronous calls using the functions runs and waitsFor:<ref name="Asynchronous Calls">https://www.inexfinance.com/en/blog/2013/1/25/jasmine_for_clientside_testing</ref>

*runs – takes the asynchronous function for execution;
*waitsFor – takes three parameters: the first one – is a latch function that should return true if the asynch call made in runs was executed, the second one – is a failure message, and the last one - is the waiting time in milliseconds.

describe "Asynchronous", ->
a = 0
async = ->
setTimeout((-> a = 5), 1000)
it "asynch executes code", ->
runs(-> async())
waitsFor((-> a == 5), "the value should be changed", 3000)

=== Jasmine Clock ===
The Jasmine Clock is available for testing time dependent code.It is installed with a call to jasmine.clock().install in a spec or suite that needs to manipulate time.Remember to uninstall the clock after you are done to restore the original functions.<ref name="New Features"/>

==== Mocking the JavaScript Timeout Functions ====
You can make setTimeout or setInterval synchronous executing the registered functions only once the clock is ticked forward in time.To execute registered functions, move time forward via the jasmine.clock().tick function, which takes a number of milliseconds.<ref name="New Features"/>

==== Mocking the Date ====
The Jasmine Clock can also be used to mock the current date.If you do not provide a base time to mockDate it will use the current date.<ref name="New Features"/>

Example showing the uses of jasmine Clock

describe("Manually ticking the Jasmine Clock", function() {
var timerCallback;
beforeEach(function() {
timerCallback = jasmine.createSpy("timerCallback");
jasmine.clock().install();
});
afterEach(function() {
jasmine.clock().uninstall();
});
it("causes a timeout to be called synchronously", function() {
setTimeout(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback).toHaveBeenCalled();
});
it("causes an interval to be called synchronously", function() {
setInterval(function() {
timerCallback();
}, 100);
expect(timerCallback).not.toHaveBeenCalled();
jasmine.clock().tick(101);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(1);
jasmine.clock().tick(50);
expect(timerCallback.calls.count()).toEqual(2);
});
describe("Mocking the Date object", function(){
it("mocks the Date object and sets it to a given time", function() {
var baseTime = new Date(2013, 9, 23);
jasmine.clock().mockDate(baseTime);
jasmine.clock().tick(50);
expect(new Date().getTime()).toEqual(baseTime.getTime() + 50);
});
});
});

= Behavior Driven Design =

= Drawbacks =

= References =
<references/>

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T22:16:26Z

Sngala:

CSC/ECE 517 Fall 2014/ch1b 26 sa

2014-10-04T21:49:21Z

Sngala: