Worcester State University Computer Science Department
- Ludwig Van Beethoven
- Song of the Open Road
- Understanding the Simple Factory Idiom
- Using Old Test Documentation
- Testing vs Checking
- Mutation Testing
- Determining how long it will take to test.
- Week 5 – 6 Tips For Making Time to Test
- Week 4 – Criteria For Picking An IDE
- TestLink(Week 5)
- Week 3 – When To Stop Testing
- Ultra Code 2016-10-21 00:04:00
- Week 2 – An Inside Look At Testing
- How can SQL help your testing abilities? (Week 5)
- REST API Security
All posts syndicated from other blogs are the property the original author, are subject to the copyright and licensing terms of that blog, and are used here with permission of the author.
All posts original to this blog are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Afoot and light-hearted I take to the open road,
Healthy, free, the world before me,
The long brown path before me leading wherever I chose.
Henceforth I ask not good-fortune, I myself am good-fortune,
Henceforth I whimper no more, postpone no more, need nothing,
Strong and content I travel the open road.
You road I enter upon and look around, I believe you are not all that is here,
I believe that much unseen is also here.
Here is realization,
Here is a man tallied — he realizes here what he has in him,
The past, the future, majesty, love — if they are vacant of you, you are vacant of them.
Gently, but with undeniable will, divesting myself of the holds that would hold me.
I inhale great draughts of space,
The east and the west are mine, and the north and the south are mine.
I am larger, better than I thought,
I did not know I held so much goodness.
All seems beautiful to me.
— Song of the Open Road, by Walt Whitman.
The goal of the simple factory idiom is to separate the process of creating concrete objects to reduce the dependency of the client from the concrete implementations.
To implement the simple factory we need three things:
- A factory, the pizza factory.
- The products the factory makes which are the pizza objects.
- The client that uses the factory, which is the pizza store.
So, let’s take our pizza creation code, encapsulate it, separate it. And we’ll encapsulate it in a class called Factory.
Why a Factory? Because this is a class whose sole responsibility is creating pizzas — it’s a pizza factory.
To do that we’re going to take this conditional code for creating pizzas and put it into a separate class, in a method name createPizza. Each time we want a pizza, we’ll call the method, pass it a type, and the method will make a pizza for us and return an object that implements the pizza interface.
Now all this creation will be in a separate class, nicely separated form the restaurant code. So, let’s integrate this with our client code or restaurant code. Let’s assume that we’ve created a factory object already. And call it to create the pizza, passing it the type variable.
Our order pizza method no longer has to worry about the concrete type of the pizza. It could be a veggie pizza, a cheese pizza, or a pizza we haven’t even heard of yet. We know whatever type gets returned by the factory, it implements the pizza interface. And that’s all we care about.
So we call this object design the simple factory idiom.
We start we the client of the restaurant, the pizza store. And then we have our factory. The factory is the only place the concrete types of pizzas are known. And then we have the products, what the factory makes or pizzas, and there could be many concrete types of those.
To generalize this a bit, we could look at the same diagram without pizzas.
And here we have the client, a factory, and a set of products that implement a common interface.
Now, one thing to note. This is not a full fledged official pattern. It is more of an idiom that’s commonly used. That said it is the first step to understanding some of the more common design patterns.
And now we’ll put everything together in a main class called the pizza test drive which will create a pizza store and use it to create pizzas.
When a new feature needs to be tested on a program sometimes testers will use old test documentation of a similar feature to help create tests. This is not an ideal way to create tests. I was unaware people did this and I thought it was a good idea until I did some more research.
Old test documentation gets out dated very fast. Testing is improving and changing constantly so using an set of tests might not be the best way to create a test. Also the program and environment may have changed, if this is true the old tests will not be helpful. So I’ve found that in most situations tests should be created from scratch to avoid any issues and also use technology that’s up to date.
What is the difference between testing and checking? Some people may say it is the same thing, but there are some large differences. For example a human cannot perform checking, only a tool or machine can do that.
I did not realize there was a difference between testing and checking but upon reading this blog post and doing some research I found that there is one main difference. Testing is something humans do, when we analyze a program and create tests based off what we have learned, this is testing. Checking is something that a tool does to check a program. Checking is done one way by using algorithms to run through a program and perform checks based on the algorithm. That is the most important difference between the two, they both cannot be the same.
What is mutation testing? According to STH team member Swati S,
Mutation testing is a fault based testing technique where variations of a software program are subjected to the test data-set. This is done to determine the effectiveness of the test set in isolating the deviations.
Examples of mutation operators
- Arithmetic operator replacement
- Logical connector replacement
- Statement removal
- Relational operator replacement
- Absolute value insertion
How Do You Know If Your Data Set Is Effective?
You know that your data set is effective if it kills all mutants. This means that when you plug in a data set value into your program, you should expect the output to give you an error.
Mutants To Avoid
Incorrect Syntax: Mutants need to be syntactically correct.
Ex. If age%%14 (incorrect syntax)
Ex. If age> 14 & age>14 ‘means the same thing as age>14’
Ex. ‘remove the doctor assignment statement’
When it comes to estimating the amount of time a project will take one must consider the subproblem, how much time will it take to properly test the code. This turns out to be a very difficult task. There are so many variables that influence testing time.
One of the large factors in determining how long it will take to test a particular project is the team. How large is the testing team? How often does the team work together? Do members come and go? What is the skill level of each of the members? Is this the teams only task? All of these questions affect how efficiently a testing team can work together which in turn can help determines how long testing will take.
Another large factor in figuring out testing time is the complexity of the code. Obviously the more complex the code the more complex the testing process. Some programs just need to be tested to show the can take in a set of data and properly process it. Other programs have many possible paths though the code and each one must be tested.
The quality of the code that needs testing plays a role in the testing process as well. If the development team produces high quality code that is not laden with bugs the test process can move faster, but if there are many errors in the code the test team may be held up as the developers work out the bugs or will need to take the time to correct the errors them selves.
You must also keep in mind the importance of an error free program and the consequences of errors. Based on the answers to these questions you can determine what level of coverage is required. If the code is for a piece for medical equipment or part of a flight control system the consequences can be very severe. Cases like these obviously demand much more attention than the code for, say, a video game.
To actually start putting a number on the time for testing, it is a good idea to start logging data for each project. This data can then be looked at to help predict future projects. It can also help to show areas where the process can be bettered which will lead to a more efficient process and shorted estimates.