Monthly Archives: October 2016

Buddy System (Week 4)

Chronicles of Testing posted an interesting article on pair testing on October 27, 2016. Jyothi Rangaiah elaborates on how pair testing has helped her as a software tester.

Pair Testing is a technique where two team members work on the same build on the same machine. One team member works with the mouse and keyboard and the other takes notes and makes scenarios.(From Midfiretesting blog)

Jyothi Rangaiah  states that pair testing is for everyone testers and non testers alike. This is because pair testing is for anyone who wants to learn about testing. Pair testing is also for anyone who wants to get help with testing. Pair testing is also for anyone who wants to share their ideas. She states that pair testing is a good experience for management and coders to analyze a problem together.

When pair testing the result is almost always a combination of both participants and turns out better than the effort of one tester. There are obvious faults in pair testing though. Some of these faults are if the pair do not get along or if the test only requires one person to work on it.

To find out more check out both the blogs listed in this post.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.

Unit Testing with Mock Objects (Week 6)

This article is posted by IBM and explains how the Mock Object can be used. In this article we will find some of the benefits of using Mock Objects for writing Unit tests for objects that act as mediators. Unit testing has become widely accepted for software development. When you write an object you must also provide an automated test class containing methods that put the object through its paces, calling its various public methods with various parameters and making sure that the values returned are appropriate.When we’re dealing with simple data or service objects, writing unit tests is straightforward. However, many objects rely on other objects or layers of infrastructure. When it comes to testing these objects, it is often expensive, impractical, or inefficient to instantiate these collaborators. For example, to unit test an object that uses a database, it may be burdensome to install, configure, and seed a local copy of the database, run your tests, then tear the local database down again.A mock object conforms to the interface of the real object, but has just enough code to fool the tested object and track its behavior. For example, a database connection for a particular unit test might record the query while always returning the same hardwired result. As long as the class being tested behaves as expected, it won’t notice the difference, and the unit test can check that the proper query was emitted.

Here are some of the common coding style for testing with mock objects:

  • Create instances of mock objects
  • Set state and expectations in the mock objects
  • Invoke domain code with mock objects as parameters
  • Verify consistency in the mock objects

Citation
https://www.ibm.com/developerworks/library/j-mocktest/


From the blog Table of Code by Andon S and used with permission of the author. All other rights reserved by the author.