I chose this topic because I tend to forget exactly what kinds of tests are being done when system testing is mentioned. The term is very vague so I thought it’d be smart to write my own explanation of it. I chose the specific article “What is System Testing?” because I’ve used articles from this website before and have found them to be helpful.

To start, system testing is the testing of a complete and integrated software system. The important part of this is to recognize an entire system and not just one program. Interfaces, programs, and hardware are integrated frequently and there needs to be a way to test how they all work as a system. System testing is how this can be achieved.

System testing is one type of black box testing (as opposed to white box testing). System tests examine how software works based on a user’s perspective. One of the things being tested are the fully integrated applications in an end to end testing scenario. This checks for how components interact with each other as well as the system as a whole. Inputs in the application will be tested and compared to what is the expected outputs are. Lastly, a user’s experience is also part of the system testing to ensure the system flows and can be navigated smoothly by the end user.

While system testing is extremely important it’s not the only type of testing needed and it’s important to realize when it needs to be conducted. Typically it will be towards the end of the development cycle as most of the system needs to be operating correctly in order to properly execute the test cases. Unit testing and integration testing will come prior to system testing and usually acceptance testing will follow.

While there are quite a few types of system some of the more popular types include usability, load, regression, recovery, and migration.

After reading this article I definitely have a better and clear understanding of what system testing is. I think this article gave good explanations and included a helpful video as well. In order to actually implement system testing on a project I’d need to do some further reading on one of the specific types in order to decide what type best covers my system. I haven’t had the need to really implement system testing so far mainly because my programs have been relatively simple. As I head to the work force this type is testing will become very important working on much larger systems.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Mediator Pattern

      This week, I chose to talk about a blog I found that went over the mediator design pattern and its implementation. The blog post starts off by explaining that the mediator design pattern is a famous pattern found in the Gang of Four book. It is known to reduce coupling between classes that can communicate with each other. The basis of this pattern is to create a mediator object that has control over the channels of communication between the objects. All messages to other objects essentially must go through the mediator to be directed to another object. The blog post says that this eliminates the need for the deploy objects to have knowledge of the receiver objects. The post goes on to talk about the removal of direct dependencies as it can simplify communication in programs with a large number of classes. It then talks about some of the positive effects this may have like making the code easier to read overall and the maintainability for future editing. The post then goes on to explain the pattern with an example that uses communicating between colleagues and mediators within a project.

      I chose this blog because it was a design pattern that focused on communication between classes which I find very interesting. I found that the explanations this blog uses makes it very easy for me to understand how this design pattern works. The easy to digest wording allows for an easy read that works well with the examples used. The phrasing within the examples allowed the UML diagram and the definitions of the classes underneath to make more sense. The only issue I had was with following the code at first glance due to the fact that it was written in C# but it didn’t take me long to piece it all together. The test classes were well written to show meaningful variable names as well making it easier to understand the parallels they were making from the examples. Through this information I was able to learn that if there is a mediator it can be implemented to make sure all the objects don’t hold unnecessary amounts of code in terms of communication. This will cut down on code within class heavy projects that need objects to remember each other’s addresses. This will help me in my future practice by making the code run much more efficiently and create a better sense of organization that makes it easier to read when dealing with many classes.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer

This blog discusses various techniques that can be used to make your code cleaner and easier to understand. Writing high quality code is very important for software that is updated over time, and the following tips will help improve your code readability and quality.

Variable and Method Names

• Use names that reveal the intention of the variable or method
• Use names that can be pronounced
• With programming languages that support namespaces it is better to use them rather than prefixing names
• Use one word per concept throughout the program. For example, don’t use get and fetch to do the same thing in different classes
• Use solution domain names
• Use verbs for method names and nouns for classes and attributes

Better Functions

• The smaller the better
• A function should only do one thing (single responsibility principle)
• Less arguments are better
• Functions should only do what the name suggests and nothing else
• Avoid output arguments. If returning something is not enough then your function is probably doing more than one thing.
• Throwing exceptions is better than returning different codes dependent on errors
• Don’t repeat yourself

Comments

• Don’t comment bad code, rewrite it
• Explain your intention in comments
• Warn of consequences in comments
• Emphasize important points in comments
• Always use doc comments
• Any comments other than the above should be avoided
• Never leave code commented. With source control software you can always revert back to old code. Comments can be used when debugging or programming, but commented code should never be checked in

Code Smells and Anti-Patterns

The following should be avoided:

• Dead code
• Speculative generality
• Large classes
• God object
• Multiple languages in one file
• Framework core modifications
• Overuse of static
• Magic numbers (should be replaced with const or var)
• Long if conditions (replace with function)
• Call super’s overwritten methods
• Circular dependency and references
• Sequential coupling
• Hard-coding
• Too much inheritance (composition is better)

I selected this blog because being able to write high quality code is extremely important in software development. Quality code decreases time spent trying to understand it, making the code easier to maintain and reducing the possibility of bugs. I thought this blog was very well done because it was entertaining to read and gave plenty of examples. Reading this blog helped cement ideas that I learned previously from this class and taught me new techniques that increase code quality. Since none of the information is hard to understand I can begin applying what I’ve learned right now, and hopefully I will continue to get better at writing clean code.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.