Category Archives: Software Testing

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.

Wireframe Testing

A lot of software testing focuses on testing the code, which is very important, but there is another area of testing to consider, the user experience. When it comes to designing a product it is important to keep in mind who will be using it and what they are expecting. This area of testing ranges depending on the nature of the software. If, for example, you are developing software that is to be server based and will be run from command line it will require less time than a program that is to be used by the average employee.

It is a good idea to start this testing before you have invested too much time in developing the final user interface. A quote by Frank Lloyd Wright that summarizes this is “You can use an eraser on the drafting table or a sledge hammer on the job site.”

One way to accomplish this is to make use of wireframe testing. Wireframe testing is a method of testing that involves generating a mock up so that the end user can get a feel for what the final program will look like and how it will behave. There is also a variation where an expert analyzes the software instead of the end user.

Wireframes can vary in details. The simplest form may be a simple sketch the allows the user to see how items are laid out. More detailed wireframes fall into to categories high fidelity and low fidelity. Low fidelity wireframes are mock ups that provide a fairly similar look to the final product and some functionality where as high fidelity wireframes are very similar to the final product in look and feel.

Original Articles:
http://curioustester.blogspot.com/2015/08/wireframes-testing-part-i.html
http://curioustester.blogspot.com/2015/09/wireframes-testing-part-ii-how-did-i-do.html

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Test Driven Development

This week I was reading a book called Test Driven Development by Viktor Farcic. The first chapter is about why we need TDD.

The book list a few problems that all software developers face. I have listed a few from the book:

  • Most, if not all, of your tests are manual, or you don’t have tests at all.
  • Automated tests are written and executed when it’s too late for them to provide any real value for the project.
  • The maintenance cost is too high.
  • Documentation is never up to date.
  • Team is spending too much time trying to figure out what some method or class does.

TDD does not magically solve any of these problems, but it sets us in the path toward the solution. TDD speeds up the time-to-market, enables easier refactoring, helps to create better design, and fosters looser-coupling.

The book goes on to explain something called the Red-Green-Refactor process. The procedure is simple:

  1. Write a test
  2. Run all tests
  3. Write the implementation code
  4. Run all tests
  5. Refactor
  6. Run all tests

Speed in key in this process; never spend more than a minute on writing tests or implementation. It’s like a game of ping pong, the game is very fast. Write a short test and run all tests (ping), write the implementation and run all tests (pong). Repeat until it’s time to refactor and confirm all tests are passing (score). It is important to understand that TDD is not about testing, it is a process to develop high quality software fast.

The two really interesting side effects of TDD are Executable documentation and No debugging. In TDD the tests serve as the documentation. If wan’t to find out what a particular method does, read the tests associated with it. This solves the problem of out of date documentation.

The second side effect is that we almost never need to debug applications we’re working on. We almost never debug because there is rarely a reason to debug. When the tests are written before the code we can have high confidence that the code is working as expected. And since we build the software in very small steps, any errors that might occur is very easily resolved.

I went on to read and follow chapter 3 and it really helped me improve my understanding of TDD.

 

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Old School Testing

We as humans are naturally built to adapt to changes. One of which includes the adoption of new forms of testing techniques for program testing. In today’s modern technological society, you would be crazy not to take advantage of the various benefits automation testing has to offer. Like, why do the testing by hand when you can have a computer do it for you?

I read an article this week that addressed that very same question; why do we need manual testing? The article entitled “13 Reasons Why Manual Testing Can Never Be Replaced” (http://blog.testlio.com/13-reasons-why-manual-testing-can-never-be-replaced) sheds some light on why manual testing should still be a relevant and significant form of testing. Out of the 13 reasons that were mentioned, there were particular ones that stuck out to me. One reason was that “bugs are found where you least expect them” meaning that by manually testing, you may find bugs you weren’t intentionally trying to find which can’t be done with automation testing because it can’t catch issues that the testers themselves, are unaware of. I found this quite refreshing because its true; tests cases can’t exceed the scope the developer intended it to have. Another reason I found to be interesting is that “mobile devices have complicated test cases”. This is something that can quickly become a nuisance because while an automated test case may take a while to program and create, manual testing for that same test case may take much less time and effort. So while new technological developments are progressive and useful, sometimes you just got do things old school.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.