Monthly Archives: November 2017

Stubs, Mocks and Service Virtualization

We’ve been discussing the differences between stubs and mocks, along with the fact that many software testers may initially assume the two are the same concept. But as we have learned, mocks and stubs are not synonyms; they are two different techniques used within unit testing.

I wanted to learn more about some specific differences between stubs and mocks, such as potential advantages and disadvantages of using each of these techniques. Wojciech Bulaty has an informative article on the subject. Before getting into the pros and cons of each aforementioned technique, Bulaty explains the main concepts of stubs, mocks, and service virtualization.

He asserts that stubs use hardcoded data within the testing program itself, where the tests depend on this data. Based on Bulaty’s description of stubs, it seems it would be most beneficial to me to apply stubs when testing simpler code where no more than minimal implementation of an interface is required.

Mocks on the other hand seem to be most useful in situations for larger, more complex tests to “verify output against exceptions.” In my opinion, mocks ought to be used in addition to stubs to further satisfy the integrity of our testing. For instance, mocks may produce findings that stubs could not, due to the limitations of the hardcoded data within stubs. On the other hand, I feel it may be useful to use stubs as well, to help compare its findings with that of the mocks within our tests.

Bulaty introduces a third method to use within our unit tests: service virtualization. I found this particularly interesting because we haven’t discussed much about service virtualization in class yet, and this article helped me learn more about it. He explains that service virtualization supports testing through multiple protocols, and employs “test doubles” which are usually offered as Software as a Service (SaaS). It seems to me that service virtualization relies more on recorded data from a wide scope of different projects, whereas stubs and mocks are typically written by developers of their own projects.

My main takeaway from this article was recognizing some differences in particular between mocks, stubs, and service virtualization that were previously a bit unclear to me. Whereas stubs seem to concentrate on state verification, mocks tend to be more focused on behavior interactions within our code. I also learned which testing techniques may be most appropriate in regards to the particular code we are testing. For instance, if I am testing simpler tests with limited resources, based on what I’ve learned from this article, I will likely use stubs for my testing. But for larger, more complex tests, I feel I ought to implement mocks within my testing as well. Finally, when I am involved in large scale projects during my professional career, Bulaty’s article has convinced me that I should look into using service virtualization in addition to stubs and mocks when performing unit testing.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

B9: Chain of Responsibility

Chain of Responsibility

This week I chose to write about a blog that talked about the behavior design pattern known as the chain of responsibility. The post explained that behavioral patterns are used to build foundations that allow objects to communicate and give each other jobs to do. The chain of responsibility pattern makes it easier to chain objects into an order set and when a logical requirement or command is sent through the chain, it checks through the chain until an object is found that fulfills this requirement or command. It then goes on to explain some real-life applications for this design pattern like government and business systems where there is high value in order of commands. The post also clarifies that in the chain of responsibility the order moves upward rather than downwards which means that it starts at the bottom of the list and moves up. There is code shown afterwards that shows how the pattern works in a programming setting using book titles as an example. Using book titles, authors, and cover types, a chain of responsibility is created and tested by calling those objects based off one of those specific properties.

This post really interested me because it was noted as a foundational design pattern which made it seem important to learn. The examples were helpful in this post as they allowed an easier understanding of the material using real code. The analogies that were used could be a bit better but overall, they weren’t too hard to grasp. The real-life applications that were shown were interesting but in my opinion there could have been more explanation as to what specifically this pattern could accomplish within business and government. The blog helped me solidify the idea that the chain of responsibility is created with objects and goes through each object to find the specific requirement needed. I did not know that the chain started from the bottom and went upwards which is good to know but I would like to know more about the efficiency of the order in the chain. More specifically, is there a way to efficiently order the objects in the chain to make it run faster? Does the order matter within the chain enough to influence efficiency? These were some questions that I still had after reading this post, but it was a good source of information to help me get an introduction to the design pattern. This material affected me by showing be a new way to code using a foundational design pattern. This will affect my future coding practices as I can now identify situations where I can apply this pattern to make it easier to organize and run better.

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

Java Testing Tips

Since I would consider myself a novice with Junit and java testing, I decided to take it upon myself to try a learn a bit more about it since we have been using it in class. I found a blog on ZeroTurnAround.com by David Salter that discusses a few tips on this topic, which I found to be quite insightful, so I am hoping to relay those tips to you.

The first tip is to follow the AAA pattern when writing tests. That is Arrange, Act, Assert. Arrange the conditions at the start of the method, act on the system, and then assert that the results are what you expected them to be. I am always a fan of easy ways to remember things, so I really like this acronym. It a nice easy way to remember what a good java code test should include.

To go along with the AAA, there is an important thing to remember when using the last of the A’s, assert. Although assert is a cool and powerful feature, you must be careful as to where and how often you use them. One should be careful that they are not testing things that the method wasn’t intended to test. It is also important to make sure you are not testing too many things in one method. This cause headaches if a tests fails, because it requires debugging multiple methods/classes, rather than being able to focus on just one. This tip really stood out to me because I think one can easily go down this rabbit hole thinking that they are making their lives easier, while in reality they are making it harder.

The last item I want to discuss is important to testing, but it is also important with regular development as well. Take advantage of what the software has to offer you. It can make your life a lot easier in the long run if you take the time to learn a new feature or two. Although you have to invest time upfront learning how it works, you can save a lot of time because that feature makes it easier for you to develop, debug, etc. For example, libraries like EasyMock and JMockit allow you use a mock object. This allows you to “mock” objects that do not exist yet. The example used in the blog us mocking a security system that controls who can access what, depending on the user logged in. Because you are able to create a mock one, you are still able to test your product, even though a key component is missing.

Obviously there a lot of different tips a whatnot to help make us better testers. This really is just the tip of the iceberg, but I hope it was as useful to you as it was to me.

Link:

https://zeroturnaround.com/rebellabs/top-testing-tips-for-discriminating-java-developers/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Some Traits of Smelly Designs

In the past, I have talked about Code Smells. However, did you know there is also a Design Smells theory? What’s the difference? Well, according to the CodeOps blog, “Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.”. In other words, the difference between code and design smells is Design Smells focus on the design quality and principals (the architecture of the code) while Code Smells focuses on poor coding practices (what bring the architecture to life). The blog mentions a couple of red flags to look out for the may be an indication of Design Smells that I feel are worthy of discussing. Since I know I have perhaps accidentally or perhaps out of laziness have done some of the thing mentioned in this blog, I figure it can a good learning experience for both myself and the readers of this blog.

Violation of design principals: They use the java calendar class as an example. Not only does it support dates, but it also supports time. Since it has multiple roles, it is in clear violation of the Single Responsibly Principle (the first of the SOLID principals discussed a few weeks back). This is known as Multifaceted Abstraction smell. When you think about it, violating design principals is clearly a bad idea. The principals are there to promote better design and coding, so going directly against is clearly not the brightest idea.

Inappropriate use of design patterns: This one is on the opposite end of the spectrum. Instead of complete ignoring common practices to promote better code, you force it upon yourself. Just because the design pattern could be used in whatever situation you might be in, it doesn’t mean that it should be. Don’t feel obligated to use them if you feel if it will do more harm than good.

Language Limitations: Sometimes languages force you to do thing you don’t want to do, and often times it can be out of your control. Java is used as an example again. Because java does not support primitive types, if you need to take in different primitive types, you will need repeat the code, with the type taken in being the only difference. While I agree that language limitations can promote bad practices, I don’t know if it is fair to considered this to be a trait of a smelly design since unless you were able to pick the language, there is largely nothing that can be done about it.

Viscosity: This is basically taking the easy way out. Sometimes there is a hacky way to solve a problem that may be prone to errors, isn’t modular, etc., but it saves significant time and resources. Because developers are often under a time crunch, they often resort to this. I know I have, but I also know it will come back to bite you. Avoid the hack if possible.

Obviously, there are various other causes of smelly designs, but I hope this short list gave you a good idea of what Design Smells is all about.

Link:

http://www.codeops.tech/blog/linkedin/what-causes-design-smells/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Most Used Programming Languages

https://www.inc.com/larry-kim/10-most-popular-programming-languages-today.html

This article lists the top ten most commonly used languages for programmers in the real world industry. It also talks about each one for about a paragraph explaining its strengths and weaknesses, as well as what specific fields of programming use each. Since I am still learning programming, it makes sense to see which ones are going to be in higher demand as i seek jobs after college. Knowing more languages is like having more tools under your belt to solve a problem, and being able to put more down on your resume will set you apart from other candidates.

The programming language with the number 1 spot in the top ten list, is java. Java is mainly used for building server-side applications, video games and mobile apps. It is the most commonly used language because a lot of developers start by learning java first, since it is fairly user friendly. Java excels at being able to run on multiple platforms, as it is designed with the concept of WORA (write once, read anywhere).

The second most popular language is python. This is interesting news to me because I’m not very familiar with python, so now i might just look into it a bit further. Python is a general framework for mostly anything involving coding, you can find it anywhere and write pretty much anything using it. It is credited as the easiest programming language to learn because of its uncomplicated syntax, so if you already know a language its very easy to adapt to python.

Moving a bit further down the list, number five is JavaScript, which is entirely separate from the language of java. JavaScript is mainly used for online web applications. This language makes it very easy for developers to create interactive elements to their website and allows a lot of online customization options.

Also pertaining to web development, number six is PHP (personal home page, renamed to Hypertext Preprocessor). PHP is a very heavy duty language, used for dynamic big data websites, making it a great language to learn for any aspiring web developer. Another great feature is that PHP is a completely open source language, meaning the community has created many free modules anybody can use to perfectly fine tune their program to fit their exact needs.

The last but not least language on the list is C. C is the basic programming language that modern object oriented languages such as java and C# were built off of. The advantage to knowing C is that you have an understanding of the bare-bones of your code, being very close to how the machine reads it. C is more of an academic language, taught in colleges but not very used in the industry, although the knowledge and experience you gain from learning C you can use anywhere.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Most Used Programming Languages

https://www.inc.com/larry-kim/10-most-popular-programming-languages-today.html

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

7 Ways to be an Efficient Software Tester

Link to blog: https://testlio.com/blog/how-to-be-an-efficient-software-tester/

Currently as a college student majoring in Computer Science, I made the decision that I wanted to do a concentration in software development instead of data analytics. This is because my passion is to become a video game developer. While learning on the concepts of how software is designed and tested, I wondered what would be the necessary fundamentals of being an efficient software tester besides learning all of the test cases, techniques and terminologies. In this blog written by Willie Tran, he explains the seven tips on how an efficient software tester should be.

First, Tran identifies that sometimes, testing software can be chaotic and relates it to those who have experienced it in working in the field.

“Anyone who has been working in the field for any extent of time has experienced unreasonable lack of organization, poor scheduling, and daunting bug reports. Working through this mess is a task of its own. The best way to avoid this situation is to create order in your own habits. If you can create a common and consistent order for any work you touch, then you will set an example for your colleagues.”

Later, he highlights the tips that a software tester should do to be successful and efficient. These tips include organize everything, write detailed bug reports, write clear test cases, take part and communicate, ask yourself questions, be positive, and don’t test.

Organize Everything:

Creating an organize structure is important. When you create an organized structure to store all of the important details, it is easier to gather the relevant details and and perform the right testing strategy for the specific assignment you’ve been given.

Write Detailed Bug Reports

Writing clean, detailed bug reports helps a lot, especially if you’re working in a team. This means that if you do this, your team will be able to understand more clearly on what it is you are writing and what bugs that you’ve identified in your project. Tran also adds that the three points that he stresses when it comes to writing these reports are:

Write with detail
Write with clarity
Write for others

Write Clear Test Cases

Don’t create long test cases. Try to simplify as much as you can to avoid problems and save time.

Take Part and Communicate

If you are working in a team, communication is key. This makes it so that testing is a team effort. If everyone knows what they are doing with each other as well as what their tests do, the testing process will be successful.

Ask Yourself Questions

Asking questions to your self is also important in a sense that you are checking yourself as you go to see what can you do to improve the tests and make them more efficient. Ask yourself what the tests are answering and doing.

Be Positive

Testing with a positive attitude, especially in a team can be a huge factor and contribution. If your team sees that you have confidence in your work, everyone can become successful in the effort towards creating tests.

Don’t Test

Don’t test at all at the start. Once you make the tests, see what parts of the tests need improvement. Once you’ve done that, then you can test.

This blog by Willie Tran helped me understand on what an efficient software testing looks like. I picked this blog because I wanted to know more about what makes a software testing efficient besides knowing all the concepts of software testing. Knowing these tips will help me in the future to become a video game developer because most of the time, I’ll be working in teams when testing and creating game software. It will be important for me to communicate with my team and stay positive throughout the process when I work and test the softwares.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

11/6/17 Software Development

Manifesto for Adaptable Software Development

This post is from the same blogger as last week’s. This post is about the manifesto of software development. The blogger gives a list of activities in to columns. The left columns are activities that faces challenges on the right column in software development. The blogger briefly goes over what they mean and gives an example of each. Experimentation instead of Specification: Instead of writing software program with specifications, write a software program with room to experiment and make changes along the way as needed.Example: Build a minimum viable product which allowed the programmer to delay decisions until the last responsible moment. Sound engineers build flexible software platforms to support cost effective experiments. Evolution instead of Implementation: Instead of writing the system for implementations write it where there is room for it to evolve over time. Example: Domain modeling allows users to capture the essential aspects of an application while enabling future specializations. Adaption instead of modification: Write code that can easily be changed over time when needed, instead writing code with the modified changes and no room to make future adjustments. Example: Frameworks with several alternative components that may be chosen at a time needed. Extension instead of growth: Instead of writing a system for allowing the code grow overtime, create extensions making easy access to change the code when needed. Example: Plug-ins allow the user to add new features to an existing application without increasing its size or complexity.

This was an interesting blog. This blog how software development changes over time and how to keep up with the new changes. I like the example the blogger gives for each item on the list. They gave me an idea on how to adjust code when needed. This also give me a better idea of what plug in are. I’ve seen the word in the past on my computer when I try to run a game or a video on the internet. Shortly after that I am notified to update the flash on my computer and then usually the gam or video starts working again. Sometimes it does’t but that’s when the computer is old and outdated. Framework is something I already knew from this class and several other previous classes I took. This blog gave me a better idea on how frameworks can help make adjustments to coding over time, by being able to add and move parts at different times when needed.

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

Test Automation

Source: http://www.cigniti.com/blog/why-you-should-take-automated-testing-seriously/

This week I decided to write about Test Automation. I found a blog that talked about Test Automation. However I have never heard of test automation before so I had to do some research and find out what it was at 1^st. from what I read online test automation is basically testing programs by using other testing software outside of the application itself. Test automation has been around ever since the computer industry has been out. Testing is not like what programmers do where they just run their code in different situations and different fields and input and outputs. These test automations were people who were dedicated to testing out software not like debugging it but running it though tests. This was a much larger and more complex system that even was to be thought of as a discipline worthy of study apart from programming. With testing it was not just some AI testing the programming for incidentally, accidently but inherently for human errors and human interaction with the program. Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester. With Test Automation it should not be programmers testing out the code themselves and seeing if things work but people who have no idea about what they are working with or doing to test these codes and seeing how human action affects the program they are using.

This topic I read was kind of interesting because it talks a bit about what the first testing there was in the computer science world. To me I think that this kind of testing should be used a bit more because I don’t think that the people who are writing the code should test it all the time because there could be mistakes that you don’t notice and especially programs that are going to be used for the public having someone who has no idea about what code is and how to read it test out the program is useful. I think I would use this in real life situation when doing testing for code I write because like people say old but gold.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Refactoring

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

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: