Category Archives: Software Testing

Can test automation replace human testers (Week 7)

This article lists the pros and cons for test automation  and human testers.  This days the IT managers and directors are in dilemma because they have to decide what is better for their department to use for software testing the automated testing or the manual testing. Do they have to hire a team of software testers or would they be better using automated testing? These strategies have big difference. Both these strategies have pros and cons here are some:

Automated Testing

Pros: The main advantage of using automated testing is the speed, IT managers can use this strategy to test the code faster then manual testing and also they can re-use the automated testing tool many times that they need. Automated testing can be used ion different operating systems. It is very effective for build verification and testing.

Cons: A down side of automation testing is not helpful with UI testing, it can not be trusted all the time also it has high initial cost of tools.

Manual Testing

Pros: Manual Testing is the testing of software for bugs in the software system. Testers execute test cases without using any automation tools. Lets talk about some of the pros, companies that can’t afford automated test tools can use testers to write and execute test cases, this strategy is flexible compared to automation testing.

Cons: Manual testing can be very slow compared to automation testing. The tester have to be engaged 100% with the software and has to know the structure of it. If the tester don’t know the structure of the software can be a high chance of missing out on some bugs.

Citation
http://www.thinksys.com/can-test-automation-replace-human-testers.shtml

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

When to Mock?

Full Post by Uncle Bob

In this blog post, Uncle Bob goes over the basics when you should use mocks, and the advantages and disadvantages of using them.

He first goes over what will happen to your test suite if you have no mocks (he’s also going under the assumption that this is for a large application). The issues that arise when no mocks are used is that, during execution, your tests could take from several minutes to several hours to run. The next problem that could happen when no mocks are used is that your test suite might not cover everything. Bob states that “error conditions and exceptions are nearly impossible to test without mocks that can simulate those errors.” The example he gives for this is if you have files or databases tables that need to be deleted, this task my be to dangerous without the use of mocks. The last thing Uncle Bob brings up is that tests are really fragile if you don’t use mocks. This is because tests can easily be disrupted by faults in the system that are not even caused by what you’re testing.

This may seem that mocks are always the way to go, but Uncle Bob covers what happens when you use too many mocks (for this Uncle Bob goes under the assumption that you have mocks between all classes in your test suite). This first issue is that “some mocking systems depend strongly on reflection,” and if you have too many this can slow down your testing phase. The other thing is that, if you use mocks between all classes, you may end up making mocks that create other mocks. This can create two problems. One, the set-up code you’re using can end up getting convoluted. Two, this can lead your “mocking structure [to] become tightly coupled to implementation details causing many tests to break when those details are modified.” The last thing Bob points out is if you have too many mocks, you may end up have to create extra interfaces “whose sole purpose is to allow mocking,” and this can lead to “over-abstraction and the dreaded ‘design damage’.”

This may make it seem that using or not using mocks can lead to issues, so what is the correct why to use mocks in your test suite? Uncle Bob states that the method he uses for this is to only “mock across architecturally significant boundaries, but not within those boundaries”; this means to only mock when it comes to using any external software or anything that is rather large, like a database or web server. This way of mocking will address most of, if not all, the issues that came up when having no mocks or too many. The other thing that Uncle Bob suggests doing is to always create your own mocks and not rely on other software tools to do it. He points out that most mocking tools have their own language that can become time consuming to learn. Also creating your own mocks maybe more beneficial in the end because it forces you to name your mocks and put them in directories which allows you to use them for other tests. The other benefit to creating your own mocks is that it makes you take time to create your own mocking structure.

In the end, Bob suggests using mocking as little as possible and to strive to design tests to not use mocks.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Improving Testing Skills

I read an article this week entitled “How to Write a Test Case Structured for Your Project and Your Team” (http://blog.testlio.com/how-to-write-a-test-case-structured-for-your-project-and-your-team) which at first I did not find fascinating because as Computer Science majors, most of us should already be familiar with the general structure of test cases. However, despite the initial lack of interest I gave the article a chance and skimmed through its content and it turns out that there were some interesting test case structures that I have never heard or though of before.

One in particular that caught my attention was the “Verify-using-with-to test cases”. The article outlines the type of user of this structure to be beginning testers or employees (which is basically us once we graduate!) This test style can be applied to projects or any magnitude and is mainly focused on the actual language of the tests. The reason for the naming of this structure is because it follows the 4 key words: verify, using, with, and to. Instead of going into the definition of these 4 key terms, the example used in the article is this.

Verify: Courses send to bookstore
Using: Student ID, “Look up books”
With: Student is registered in at least one course
To: Show student courses list in student bookstore

After reading the article and going over the examples provided, I did find this particular test structure to be not only useful, but pretty easy to use so it’s something I look forward to using the next time I test!

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.

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.