Hello everyone and today’s topic for my final blog post for 443 is going to be about test double in software testing. In this article they discuss three implementation variations of testing doubles which are fake, stub and mock and gives examples when to implement them. I know from class that they are missing at least one more test double which is dummies so I’m thinking these three fake, stub, and mock are mainly used. First, fake is defined as the same as the activity we work on in class which is “fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code”. A good analogy of a short cut is a repository. Fake implementation will not be involved database but will store data using a collection which allows us to not start up the database and save more time from request when involving with integration testing. Fake implementation is also great for prototyping and spikes. Second is stub and this defined the same as the activity we work on in class too which is “stub is an object that holds predefined data and uses it to answer calls during tests. It is used when we cannot or don’t want to involve objects that would answer with real data or have undesirable side effects”. An example would be instead of grabbing from the database where design a stub like a method and controlling it’s return value. Stubs is a good option for testing query type methods which are “methods that return some result and do not change the state of the system” because you can confirm the return value of the method. Finally, mocks are “objects that register calls they receive. In test assertion we can verify on mocks that all expected actions were performed”. A good example of mock that they give is when you want to test a system like a security system that check if the window and door is closing in order for the security system to work, you don’t actually want to call the real door and window instead you can create mock window and door to test the interactions to see the functionality of the security system because the closing is a responsibility of the door and widow and that should be tested separately in unit testing. All in all, these are the test doubles they discuss in this article stub, mock, and fake and they are all make software testing much simpler.
In these 443 blogs post I am going to write about the differences between the different levels of tests. There are four basic levels of tests which are unit/component testing, integration testing, system testing, and acceptance testing. Unit testing when you separate each part of the program and test them individually and confirm that they perform what they were design to do. This is usually done in the beginning of the development and usually done by the developer first than hand over to the testing team. Integration testing is when you break the program into combinations and test if they actually work together. This exposes any flaws that show if the components don’t work together or not. There are many ways this can be tested, bottom up or top bottom. System testing is one of the higher levels of testing. It’s when you test the whole program to ensure that it all work properly and meets the requirements. This is one of the most important steps before deploying the product and it confirm that the product is almost ready to ship. This can be tested in an area where user can test the product. This usually done when a special testing team to see if the product fulfills its requirements for the business. Acceptance testing is involving a lot of user end. Acceptance testing test whether the system complies with the user end. This step is to find out many different problems that can occur like bugs that can harm the product in anyway. During this step you can find out if the program will be installed or not into the user’s system. Every single of these testing levels is important and testing early to avoid error in the future and testing for often is well worth it. This important because finding and fixing errors near the finishing stage which be more difficult and more time consuming than finding them early. All in all, these four levels of tests are important, and I learned more about those four after reading this article. It changes the way I work because I know the importance of the levels and what to do in those levels.
Today I am doing another smells blog post but this one is going to about code instead of design. This article that I am doing it on contains many of the code smells and I will be being writing about some of the things I learned from them. First, code smells within codes:
Comments – I learned to remember that comments should be written for people, not the machines. I will also try to refactor my code as possible to avoid to comments for example better method names and cleaner code, so it would be easier to understand and follow.
Long Method – I learned that shorter method is better than longer method because it is easier to read, understand, and maintain. I will always try to minimize the size of my method as small as possible to be more efficient.
Long parameter list – I learned a great to limit the number of parameters by using a object to combine it if I actually need the values of the parameters because the more parameters there is, the more complex it is.
Duplicated Code – never have code that duplicated.
Conditional complexity – don’t have large conditional logic block, use design patterns to avoid this problem.
Combinatorial explosion – I learned that this is when we have lots of code perform the same operation but have a little difference. I think the best way to avoid this is to make a method for the operation.
Large class – if a class seem too large than you can break it into smaller class, so it can be easier to understand.
Large class – if a class seem too large than you can break it into smaller class, so it can be easier to understand.
Also, Code smells between classes:
Data class – I learned to avoid class that only data because a class should have data but should have method to manipulate the data.
Lazy class – this just means that every class should be important enough to be a class.
Shotgun surgery – this means that you should avoid making a class that effect other classed when making an update.
Solution Sprawl – this is when you have need multiple class to do one thing, it’s better off to simplify the code.
All in all, this article has All in all, this article has code smells and I learned a lot from them. I now know how to avoid these smells and how to deal with them after reading this.
Hello, every and welcome to another blog post by Phan CS. Today topic is about to be about design smells. According to this article “design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality”. Design smells affect the software quality and the organization in a negatively way. The organization will be affected because the presence of the smells in the framework will be used by clients and depending of the feed back which is usually going to be negative, the whole community is going to feel the same and it’s also hard to fix design in the API when the API is already in use. There are many causes of design smells. First, when a class has multiple responsibilities this would consider a violation of design principles which they named multifaceted abstraction smell because abstraction should be unique. They had an example of this problem in the article which explains that calendar class in the java.util package support date-related functionality which it is supposed to but also supports time-related functionality as well which is a violation of design principles. Second, inappropriate use of design patterns which is when programmers try to apply design pattern because they are pressure into using them by don’t fully understand how use them and this result of too many classes. Next, is language limitations, this when two methods that support different primitive types belong to the same class and its java does support primitive types which result in it’s impossible to remove duplicate code. Also, when programmers mistakenly think classes are doing things instead of being things, this can cause problems that can result in design smells. Finally, design smell is usually created when a programmer is in a rush and is hacking the code because it requires less time and effort to do it this way. When the environment is following practice usually other programmers will so the same. All in all, design smell should be avoided because it bad for product. I thought this was interesting in many ways. This change the way I code because I will be thinking about what I am doing more.
Hi everyone and welcome to my sixth 443 cs blog post. Today I’m going to go over this article that I am certainly reading which is titled “why you need to know these 9 automated testing tools for java”. This article explains how do selenium, junit, grinder and other automated testing tools work and how to use them. Testing java applications is important because you must ensure that your program is supposed to do what it is doing. There are many automated testing tools for java, but this article goes over the most common and useful of them. First, there are different types of tools for different kinds of situations. For example, unit testing is for newly written code before its incorporated into the base of the code. Next, integration testing prevents the application from crashing from newly written code. Also, to test the performance of the application you would use performance and user experience testing. Finally, to test the vulnerabilities of the application to would use security testing. These are some the testing methods and there’s many more and some of these methods are used for multiple purposed. This article listed what the best automated testing tools for java and there are:
- Junit which is the most popular and is usually for unit testing
- Testingng which is a versatile tool because it can be used for unit test, integration test and many others.
- Jtest which is good for security testing.
- The grinder is for performance testing.
- Gatling which is also a performance testing.
- Selenium which is for interface and experience testing.
- Mockito which is good because it makes it fast and easy to write automated java test.
- Powermock which is a unit testing framework.
- Arquillian which allows you to write tests that execute in real runtime environments.
All in all, this article is very helpful and change the way I think about this subject because I did not know there was so many testing tools out there and the purpose of each testing tools. I now know what and when to use the automated tools depending on the situation.
Today’s topic for blog 6 is solid, grasp, and other basic principles of object-oriented design. This article teaches you about basic about solid and grasp languages. First, code should have the following qualities maintainability, extensibility, and modularity. These qualities are usually in code that are easy to maintain, extend, and modularize over its lifetime. This article has many examples written in java and c#. These are the principle that the article goes through:
Single responsibility principle which states that a class should have only one responsibility and a class a fulfills its responsibilities by using its functions.
Open-closed principle which states a software module (class or method) should be open for extension but for modification.
Liskov substitution principle which states derived classes must be substitutable for their base classes. What this basically means is that abstraction should be enough for a client.
Interface segregation principle which states clients should not be forced to depend upon the interfaces that they do not use.
Dependency inversion principle which states program to an interface, not to an implementation.
Hollywood principle which helps prevent dependency rot. It states that a high-level component can dictate low-level components in a manner so that neither one is dependent upon the other.
Polymorphism which they say it is a design principle.
Information expert which helps you to give responsibilities to classes.
Creator which is a grasp principle that helps decide which class should be responsible for instantiating a class.
Pure fabrication which reduces the cohesiveness of the domain classes.
Controller which is a design principle that helps minimizing the dependency between gui components and the domain model classes.
And favor composition over inheritance and indirection.
All these topics were provided examples and it was very easy to understand. I thought this article was very informative. I think it provides the basic main idea of these principles. After reading this article I changed the way I work because I now know how to apply these principles to improve my code. I agree with everything in this article but if I would to improve it, I would say to break up grasp and solid to separate articles. All In all, this article was very useful in learning the basic about different principles and how to apply them.
Hello everyone, and welcome back to my 443 blogs where I post many interesting topics that I am currently learning. Today blog post topic is about boundary value analysis and equivalence partitioning. Boundary value analysis is a testing technique where you test between valid and invalid inputs. Boundary values are also known as lower/upper values and errors are often observed in those ends. It’s considered a black box testing technique. Equivalence partitioning and boundary value analysis can co-exist and used together to test many more areas of the test. Boundary value analysis test is proficient because it can test most of the test product. Equivalence partitioning is when we categorize the values into ranges and test one input from each of category. This is also a black box test design technique and can be applied to several different test like unit, integration, etc. Equivalence partitioning would have numerous amounts of test cases that we cannot test all. All in all, this blog post is about Boundary value analysis and equivalence partitioning. The resources that I gather my information was from https://reqtest.com/testing-blog/what-is-boundary-value-analysis-and-equivalence-partitioning/. I thought this blog was good but didn’t provide much information about this topic other than basic. The examples that this blog provide wasn’t descriptive enough for me to truly grasp on the idea of equivalence partitioning and boundary value analysis. After reading this blog, it didn’t change the way I think about the subject because I already knew most of the content, but I was looking for more details. I thought the blog should of include more visual examples with actual test inputs. I learn some useful tips on this subject like for example that we can’t test all possible cases in equivalence partitioning because the test cases would be too large. Also, even though this resource was simple it’s was easy to understand the material and the example wasn’t complex, so it was easy to follow. I agree with everything in the article and like the way it explains the topic. In conclusion, this was my 443-blog post and I learned many interesting things from this recourse that I used.