Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-14T04:42:29Z

3xT: /* Deserialization with readResolve */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==

=== Serialization with writeReplace ===
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

In this example, if an instance of MyClass was to be serialized Java would look to first see if there was a method implemented called writeReplace as shown in the example. If this method does exist, the return value of this method would be serialized instead. In this example, a new instance of SerializationProxy would first be created and constructed with the integer parameter from MyClass and that object would be serialized.

=== Deserialization with readResolve ===
During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

In this example, if an object is deserialized, Java looks for a method called readResolve. If readResolve exists, the return value of readResolve is returned instead of this object. In this example, the SerializationProxy would first be deserialized and then Java will look for and find readResolve. A new instance of MyClass would then be created with the integer parameter from the SerializationProxy and the instance of MyClass would be returned as the result of the deserialization.

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-14T04:39:12Z

3xT: /* Serialization with writeReplace */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==

=== Serialization with writeReplace ===
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

In this example, if an instance of MyClass was to be serialized Java would look to first see if there was a method implemented called writeReplace as shown in the example. If this method does exist, the return value of this method would be serialized instead. In this example, a new instance of SerializationProxy would first be created and constructed with the integer parameter from MyClass and that object would be serialized.

=== Deserialization with readResolve ===
During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-14T04:37:31Z

3xT: /* Serialization with writeReplace */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==

=== Serialization with writeReplace ===
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

In this example, if an instance of MyClass was to be serialized Java would look to first see if there was a method implemented called writeReplace as shown in the example. If so as we do here, the return value of this method would be serialized instead. In this example, a new instance of SerializationProxy would first be created and constructed with the integer parameter from MyClass and that object would be serialized.

=== Deserialization with readResolve ===
During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-14T04:36:37Z

3xT: /* Serialization with writeReplace */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==

=== Serialization with writeReplace ===
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

In this example, if an instance of MyClass was to be serialized Java would look to first see if there was a method implemented called writeReplace as shown in the example. If so as we do here, the return value of this method would be serialized instead. A new instance of SerializationProxy would first be created and constructed with the integer parameter from MyClass and that object would be serialized.

=== Deserialization with readResolve ===
During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-14T04:21:16Z

3xT: /* Serialization writeReplace */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==

=== Serialization with writeReplace ===
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

=== Deserialization with readResolve ===
During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-14T04:21:05Z

3xT: /* Implementation Details */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==

=== Serialization writeReplace ===
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

=== Deserialization with readResolve ===
During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-11T19:38:19Z

3xT: /* Problem */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-08T05:08:12Z

3xT: /* What are Mock Object Frameworks? */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''

[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in jMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ jMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-08T05:07:19Z

3xT: /* What are Mock Object Frameworks? */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Diagram of showing where mock objects fit in:'''

[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in jMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ jMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-08T05:07:09Z

3xT: /* What are Mock Object Frameworks? */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Diagram of showing mock objects fit in:'''

[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in jMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ jMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-08T05:06:48Z

3xT: /* What are Mock Object Frameworks? */

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-08T05:06:21Z

3xT: /* What are Mock Object Frameworks? */

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:47:19Z

3xT:

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in jMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ jMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:47:06Z

3xT: /* Criteria in choosing a Mock Object Framework */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in jMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ jMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:45:11Z

3xT:

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in jMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Criteria in choosing a Mock Object Framework ==

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ jMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:41:48Z

3xT: /* Existing Mock Frameworks */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Object Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:40:22Z

3xT:

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== Existing Mock Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:40:05Z

3xT: /* Existing Mock Frameworks */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

== Existing Mock Frameworks ==
*Java
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:39:54Z

3xT: /* External Links */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

== Existing Mock Frameworks ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:39:22Z

3xT: /* References */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

2. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

3. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

4. [http://en.wikipedia.org/wiki/Mock_object Wikipedia - Mock object]

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:38:43Z

3xT: /* References */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. [http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches Approaches to Mocking]

3. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

4. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:38:25Z

3xT: /* References */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

4. [http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html Java Mock Frameworks Comparison]

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:37:52Z

3xT: /* References */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. [http://msdn.microsoft.com/en-us/magazine/dd882516.aspx Using Mocks And Tests To Design Role-Based Objects]

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:37:21Z

3xT: /* What are Mock Object Frameworks? */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where its responsibility is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:33:51Z

3xT:

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:33:22Z

3xT: /* Verify the expectations were satisfied */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===
This step involves ensuring that everything that was expected of the mock object was satisfied such as the number of method calls to a certain method.

An example in JMock:

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

This example shows a context that is used while using the JMock framework which is initialized at the top. At the end a method assertIsSatisfied() is called on the context. In this case, JMock uses the context to create mock objects and it is aware of what expectations mock objects had. The assertIsSatisfied() method will throw an exception depending on if the expectations of the mock objects were or were not satisfied.

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:28:22Z

3xT: /* Verify the expectations were satisfied */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===

Mockery context = new Mockery();
<Create mock object>
<Define the method stubs>
<Define the expectations>
<Execute the test code>
context.assertIsSatisfied();

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:28:04Z

3xT: /* Verify the expectations were satisfied */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===

Mockery context = new Mockery();
Create mock object...
Define the method stubs...
Define the expectations...
Execute the test code...
context.assertIsSatisfied();

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:27:45Z

3xT: /* Verify the expectations were satisfied */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===

Mockery context = new Mockery();
// Create mock object.
// Define the method stubs.
// Define the expectations.
// Execute the test code.
context.assertIsSatisfied();

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:27:36Z

3xT: /* Verify the expectations were satisfied */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===

Mockery context = new Mockery();

// Create mock object.
// Define the method stubs.
// Define the expectations.
// Execute the test code.

context.assertIsSatisfied();

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:26:46Z

3xT: /* Verify the expectations were satisfied */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===

Mockery context = new Mockery();

// Create mock object
// Define

context.assertIsSatisfied();

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:22:40Z

3xT: /* Execution of the test code */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the mocked object.

An example not specific to any Mock Object Framework:

PositionProcessor processor = new PositionProcessor();
processor.process(mockPositionProvider);

In this example we have a PositionProcessor class which processes PositionProviders. A case of code that is involved with interacting with the mocked object is when a PositionProvider is processed we might expect the getX() method to be called at least once.

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:18:22Z

3xT: /* Define the expectations */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockPositionProvider.getX() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.getInt();

In the above examples we assumed that the Role class had a method called getInt(). In this example we have an IntGetter class which is composed of a Role class. The IntGetter has a method called getInt as well, when this method is called we expect the

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:18:03Z

3xT: /* Define the stubbed methods */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.getInt();

In the above examples we assumed that the Role class had a method called getInt(). In this example we have an IntGetter class which is composed of a Role class. The IntGetter has a method called getInt as well, when this method is called we expect the

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:16:58Z

3xT: /* Define the expectations */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockPositionProvider.getX()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.getInt();

In the above examples we assumed that the Role class had a method called getInt(). In this example we have an IntGetter class which is composed of a Role class. The IntGetter has a method called getInt as well, when this method is called we expect the

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:16:32Z

3xT: /* Define the stubbed methods */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockPositionProvider.should_receive(:getX).times(1).and_return(10);

This uses chained method calls to declare that on the mockPositionProvider object the getX method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockPositionProvider object should receive getX one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockRole.getInt()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.getInt();

In the above examples we assumed that the Role class had a method called getInt(). In this example we have an IntGetter class which is composed of a Role class. The IntGetter has a method called getInt as well, when this method is called we expect the

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:15:15Z

3xT: /* Create the mock object */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

PositionProvider mockPositionProvider = mock(PositionProvider.class);

This declares a variable called mockPositionProvider which is a mock object of the PositionProvider class. This variable is initialized to have the value mock(PositionProvider.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the PositionProvider class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockRole.getInt()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.getInt();

In the above examples we assumed that the Role class had a method called getInt(). In this example we have an IntGetter class which is composed of a Role class. The IntGetter has a method called getInt as well, when this method is called we expect the

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:14:20Z

3xT: /* Execution of the test code */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockRole.getInt()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.getInt();

In the above examples we assumed that the Role class had a method called getInt(). In this example we have an IntGetter class which is composed of a Role class. The IntGetter has a method called getInt as well, when this method is called we expect the

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:12:12Z

3xT: /* Execution of the test code */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockRole.getInt()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
This step involves invoking the code that is involved with interacting with the role that is being mocked.

An example not specific to any Mock Object Framework:

IntGetter intGetter = new IntGetter(mockRole);
intGetter.get()

In the above examples we assumed that the Role class had a

=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:08:44Z

3xT: /* Define the expectations */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockRole.getInt()

This is plainly calling a method on a mocked object. In EasyMock, this is how expectations are created. Test code would be run at some point after this method call and then when the mock object is verified it will check if mockRole.getInt() was indeed called through the test code.

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:07:06Z

3xT: /* Define the expectations */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown.

An example in EasyMock:

mockRole.getInt()

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:05:18Z

3xT: /* Define the stubbed methods */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations.

An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown. An example in EasyMock:

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:04:58Z

3xT: /* Create the mock object */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations. An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown. An example in EasyMock:

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:04:49Z

3xT: /* Create the mock object */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

'''An example in Mockito:'''

*Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations. An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown. An example in EasyMock:

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:04:35Z

3xT: /* Create the mock object */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object.

'''An example in Mockito:'''

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations. An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown. An example in EasyMock:

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:04:24Z

3xT: /* Define the expectations */

== What are Mock Object Frameworks? ==
"Mock object frameworks" allow for the creation and use of "mock objects" which are used to mock existing roles in a system. Roles are identified in a system as an interface or abstract type where the responsibility of the object is made aware through its definition. Mock objects are typically provided behavior and expectations programatically to allow for testing interactions with them.

'''Where mock objects fit in:'''
[[Image:Whatismocking.png]]

== Why use Mock Object Frameworks? ==
Using mock objects allows for testing interaction with an interface rather than an implementation. There are a variety of reasons this may be beneficial, some of which may be when the mocked object is:
* non-deterministic (i.e. time of day)
* able to exhibit behavior that is difficult to reproduce directly (i.e. time out exception)
* slow (i.e. accessing a database)

An example role in a system might be a DataProvider interface. Two implementation independent features of the getData() method of this interface may be that it returns a Data object and is able to throw a DataRetrievalException. An example definition is shown below in Java:

interface DataProvider {
Data getData() throws DataRetrievalException;
boolean hasNext();
}

A mock object in this case would be useful in a test which involves the interaction with a DataProvider, such as providing data to a DataConsumer class.

'''Example of a relationship between DataConsumers and DataProviders:'''

[[Image:Mockdataprovider.png]]

The implementation of the DataProvider is irrelevant to testing the correctness of a DataConsumer. The DataProvider interface provides a layer of abstraction to the DataConsumer, this clearly defines the contract that any implementation of a DataProvider must satisfy. Creating a barrier in this fashion and using a mock object allows for creating isolated unit tests in a complex system. The alternative would be setting up integration tests where an entire environment must be setup to test one particular component.

Mock DataProviders could be configured with behavior and expectations for each test case that the DataConsumer need be tested against. Some of the test cases may be when the DataProvider:

*returns a faulty Data object
*returns a legitimate Data object
*returns null
*throws a DataRetrievalException
*throws an unchecked exception

== Typical Steps to using a Mock Object Framework ==
=== Create the mock object ===

This step involves creation of the mock object. An example in Mockito:

Role mockRole = mock(Role.class);

This declares a variable called Role which is a mock object of the Role class. This variable is initialized to have the value mock(Role.class). The mock method is a call to the Mockito framework which tells it to return a mock object of the Role class.

=== Define the stubbed methods ===
This step involves defining what methods should do when they are called. This step can be combined with the next step which is defining expectations. An example in Flex Mock:

mockRole.should_receive(:getInt).times(1).
and_return(10)

This uses chained method calls to declare that on the mockRole object the getInt method should be called, the method should be called one time, and when called the method should return 10. An important feature to notice here is how natural using the mock object framework feels here, it should be noted that many mock object frameworks strive for this type of readability when designing their APIs. Reading from left to right you can easily understand what is going on, "the mockRole object should receive getInt one time and return 10".

=== Define the expectations ===
This step involves defining what is expected to happen to the mock object when the test code is run such as what methods should be called, how many times should the methods be called, or what exceptions should be thrown. An example in EasyMock:

=== Execution of the test code ===
=== Verify the expectations were satisfied ===

== References ==
1. http://en.wikipedia.org/wiki/Mock_object

2. http://onjava.com/pub/a/onjava/2004/02/11/mocks.html#Approaches

3. http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

4. http://www.sizovpoint.com/2009/03/java-mock-frameworks-comparison.html

== External Links ==
*Java Mock Object Frameworks
**[http://mockito.org/ Mockito]
**[http://easymock.org/ EasyMock]
**[http://www.jmock.org/ JMock]
*Ruby Mock Object Frameworks
**[http://mocha.rubyforge.org/ Mocha]
**[http://flexmock.rubyforge.org/ Flex Mock]

== Test 3 ==
== Test 4 ==
== Test 5 ==

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T19:01:06Z

3xT: /* Define the stubbed methods */

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T18:56:58Z

3xT: /* Define the stubbed methods */

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T18:55:31Z

3xT: /* Why use Mock Object Frameworks? */

CSC/ECE 517 Fall 2009/wiki1a 2 i7

2009-09-07T18:55:18Z

3xT: /* Why use Mock Object Frameworks? */