This week in class, we did activities based on static testing. We analyzed code with Gradle And Gradle is not a new tool we’re just hearing about, as we’ve worked with it throughout the semester. And since it is an automation tool with a lot of cool features, I took a further look into automation in software development. I wanted to know what the best features were as well as potential drawbacks from using automation. I ended up finding a blog called “Automation in Software Development: Pros, Cons, and Tools.”

What Else can be Automated?

We’ve learned by now that software testing can be automated. But is that it? Absolutely not. There are some other important software processes that can be automated. One of them is CI/CD (Continuous Integration/Continuous Deployment). Automating continuous integration allows changes in code by multiple developers to be continuously integrated into a common version control repository throughout the day, after which tests are run automatically, making sure that newly written code is not interfering with existing codes. Automating continuous deployment results in integrated and tested code in the production phase being released automatically. Releases are quicker due to the automated deployment, and better because every new line of code is tested before even being integrated.

Automation can also be used to monitor and maintain code. There are automation tools that help analyze data, identify issues, and also provide notifications of a deployed software product. With automation, issues can even be resolved automatically. This is really helpful because it drastically reduces time and resources spent trying to correct errors.

Pros

Three of the largest benefits that come with automation are reduction in manual workload, lower development costs, and an increase in software quality. When tasks are automated, developers can use that now-free time to find ways to improve the software. This way, there is a better chance of the software having more advanced features, as well as customers being satisfied with the product. Many errors and defects of a deployed product come from human errors made during the development of the software. This is where automated testing comes in. Testing tools such as Gradle, JUnit, and Selenium were created for this purpose. Automated testing tools provide feedback on code at the snap of a finger compared how long manual testing might take, which as said before, leads to less time and money being spent to rectify errors. Reduced time and cost are two of the most key automation features that persuade businesses to use automation.

Cons

The challenges most faced when implementing automation tend to be: complexity of the tools, financial constraints, and human resistance. Automation tools can be tough for a corporation to set up and some automation tools require skills that a corporation’s employees might not have. So that means they have to be trained to use it, which means more time and money spent. Though the last paragraph mentioned how automation had lower costs, it can be quite expensive when first implemented. From purchasing the required motion control equipment to paying subscription and renewal fees, automation on a large scale seems to only be a realistic option for large companies. The return on investment might not be immediate either. There is also a concern that automation will soon replace human employees. This can create uncertainty and division in the workplace because employees might not know if they are at risk of being let go or not, so they might object to using automation.

Reference

https://www.orientsoftware.com/blog/automation-in-software-development/

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

This week in class, we took another deep dive into the world of test doubles. This week pertained to mocks specifically. While doing class activities related to mocks this week in class, it seemed to me that mocks are easier to use than stubs while offering more insight on how a program is supposed to run. With that in my mind, I took the opportunity to further learn about mocks. I ended up finding a blog that gave me an even better understanding about mocks, and it is called “Understanding Mock Objects in Software Testing: A Tale of Simulated Reality”.

One quote from the blog does a great job of summing up what mocks are. “It’s like a stand-in actor in a movie – the mock object behaves like the real one but is controlled within the testing environment.” Mocks mimic the actions of the object it replaces when called upon in a test class. Mocks check the order and frequency of method calls in which they are used, which stubs don’t do.

Frameworks

There are mocking frameworks for many different languages. Some common mock frameworks include Mockito in Java, Moq in .NET, and Jasmine in JavaScript. Mockito is popular for its simplicity. It does well to create mock objects for a certain class or database that simulates how a real object would respond in the program. Moq is primarily used for C# applications and is popular for its strong typing and fluent interface. A language with strong typing demands specification over data types, so variables must have a type when they are defined. Jasmine mocks HTTP requests, which allows front-end applications to be tested without back-end interactions.

Pros

Some of the benefits of using mocks is that they are used in a controlled and predictable environment, and they are efficient. Mocks give predetermined behaviors and don’t leave the testing framework, which leads to consistency and predictability. And since mocks are used in the place of real-world objects, the testing process is sped up. It allows testers to isolate external factors and focus solely on the code being tested. Mock testing is also a cheaper alternative to testing real-world objects that may be very expensive.

Cons

A drawback of mock testing is that while tests pass in the testing, they may not in real-world situations. And just like stubs, changes to the system can cause mocks to become outdated, so it is important that mocks are frequently provisioned in order kept up to date with any changes to the system being tested.

Example

In the example above Mockito is the framework being used. WeatherService represents the external dependency, and WeatherModule represents what is being tested. mockService should return “Sunny” when “New York” is the string in the .getWeather() method. This allows WeatherModule to be tested in isolation. module.getWeather() is then assigned to the string variable “weather”. From there, weather is tested for if it returns “Sunny”. This is fascinating because the tests compile and are ran using make-believe objects

Reference

https://www.thetesttribe.com/blog/mock-testing/

From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

This week in class, we learned about test doubles. Test doubles are make-believe objects in code that take the place of actual objects for testing purposes. Test doubles are a great resource if you are working on a team project and your collaborator’s code is incomplete or not there at all. The test doubles we went over in class are dummies, fakes, stubs, and mocks. And being honest, I didn’t have the best understanding of it at first. But creating stubs in Activity 12 gave me a greater comprehension, as well as interest in it. Upon doing a little more research on stubs, I found a blog all the way from 2007 called Unit Testing with Stubs and Mocks. The blog compared stubs and mocks to each other, as well as which test double is more useful.

Stubs

Stubs are used by implementing part of your peer’s code as a concrete class. How much of the collaborator code needed depends on the minimum code needed to properly test something in the class. A stub’s job is to do nothing more than return the expected value needed for the test to pass. Stubs can also be implemented inside the test class. This saves the tester a lot of time because the stub class now becomes a separate, anonymous declaration. As a result, the same stub does not have to be reused across multiple unit tests. And since the stub becomes a separate declaration, the number of stubs used in a project becomes significantly lower.

A drawback from this however, is that the separately declared stub does not account for any changes that your peer might make to the code. This can mean a lot of work for the tester because new methods and variables may need to be declared. As a solution to this case, it is recommended that a base class is created in the test directory of your project. This way, if a collaborator makes an update to the code, you limit the amount of work you do by only updating the base class.

Mocks

Mock objects are used to obtain a high level of control over testing the given implementation. Mock object generators such as EasyMock and JMock are great tools that create mock objects based on the class being tested. If a test fails in EasyMock, it will create an obvious message. When testing with stubs, it is uncertain whether the test will fail or not. This however leads to constant changes made to the test cases. But through constant updating, the unit tester gains a greater knowledge of the implementation.

When to Use

In the case of which is better between stubs and mocks, there is no wrong answer. There are scenarios where using stubs will fit the test better, but there will also be scenarios where the usage of mocks is the better option. For example, if you need to nest a method call on the collaborator, then stub objects are the way to go. Mocks are more robust than stubs, but stubs are easier to read and maintain. However, mock users say that it is worth it to use mocks over stubs in the long term.

Reference

https://spring.io/blog/2007/01/15/unit-testing-with-stubs-and-mocks

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

This week in class we learned about path testing, which is a white box method that examines code to find all possible paths. Path testing uses control flow graphs in order to illustrate the different paths that could be executed in a program. In the graph, the nodes represent the lines of code, and the edges represent the order in which the code is executed. Path testing appealed  to me as a testing method because it gives visual representations of how the source code should execute given different inputs. I took a deeper dive into path testing after this week’s classes and found this blog that gave me a deeper understanding of path testing.

Steps

When you have decided that you want to perform path testing, you must create a control flow graph that matches up with the source code. For example, the split of direction between nodes should represent if-else statements and for while loops, the nodes towards the end of the program that have an edge pointed at an earlier node. 

Secondly, pick out a baseline path for the program. This is the path you define to be the original path of your program. After the baseline is created, continue generating paths representing all possible outcomes in the execution. 

How many Test Cases?

For a lengthy source code, the possible outcomes could seem endless and could therefore end up being a difficult, time-consuming task to do manually. Luckily, there is an equation that determines how many test cases a program will need with path testing.

C = E – N + 2P

Where C stands for cyclomatic complexity. The cyclomatic complexity is equivalent to the number of linearly independent paths, which in turn equals the number of required test cases. E represents the number of edges, N is the number of nodes, and P is the number of connected components. Note that for a single program or source of code, P = 1 always.

Benefits

Path testing reveals outcomes that otherwise may not have been known without examining the code. As stated before, it can be difficult for a tester to know all the possible outcomes in a class. Path testing provides a solution to that by using control flow charts, where the tester can examine the different paths. Path testing also ensures branch coverage. Developers don’t need to merge code with an existing repository because the developers can test in their own branch. Unnecessary and overlapping tests are another thing developers don’t have to worry about.

Drawbacks

Path testing can also be time consuming. Quicker testing methods do exist and take less time off further developing projects. Also in many cases, path testing may be unnecessary. Path testing is used often by many DevOps setups that require a certain amount of unit coverage before deploying to the next environment. Outside of this, it may be considered inefficient compared to another testing method.

Blog: https://blog.testlodge.com/basis-path-testing/

From the blog Blog del William by William Cordor and used with permission of the author. All other rights reserved by the author.

Overview

It is very important for every software developer to be able to write clean, understandable, and maintainable code. Writing clean code will not only be confusing to the user, but it can also confuse the author who is still in the process of writing the code. In my opinion, organization and neatness is the foundation of reaching success in anything. The two main components that will decide if your code is clean are the naming of variables and how functions are written. An article I read by Yiğit Kemal Erinç explained this well.

Naming Variables

We give variables names because they are far easier to remember than its memory address, which is a mixture of numbers and letters. Names give you more information about the variable as well. Someone using your code would likely have a tough time understanding a variable just by the memory address.

The name of a variable should be meaningful. If you need to attach a comment next to the variable to explain its purpose, then you need to rename the variable. The name should already tell you the variable’s purpose and why it exists, and how it should be used. If a name requires a comment, it does not reveal its intent. 

When naming variables, it’s important to avoid disinformation. For example, a variable that has the suffix “-list”  should be a linked list. For a variable to have the “-list” suffix and not be a linked list would be disinformation and lead to confusion.

Writing Functions

There are plenty of tips for how to design clean, easy-to-follow functions. One very helpful tip is to keep the functions small. Functions should be nowhere near 20 lines long. The longer a function gets, the more likely it is to do multiple things and have side effects. From the article, the most important concept was to make sure that your functions only do one thing. If your function only does one thing, it is guaranteed that your function will be small. A good way to check if your function is doing multiple things is if you can create another function out of it. As for side effects, unintended consequences of your code. Side effects can involve changing passed parameters and global variables, which will leave your code tangled up.

Conclusion

Clean coding is not a skill that you learn overnight. Like anything else you want to be good at, it takes practice and repetition. When you write code, make a habit of the clean code principles, so it becomes second nature.

Source

https://www.freecodecamp.org/news/clean-coding-for-beginners/

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.

Overview

This week in class, my group and I installed Java in VSCode and created a unique file to write code in. It was the first time that I created a file that wasn’t in BlueJ or ZyBooks in order to write runnable code inside of. Being it was my first time experimenting with it, it took a while for me to understand. But once it became clear to me I found it very interesting. A tutorial on getting started with Java in VSCode I read went further into detail on how to use Java in it, covering tools, testing, project management, what needs to be installed and many other helpful things.

Installing Java

To first get started a coding pack needs to be installed. There’s a link leading to the files that need to be downloaded. However, the Development Environment activity we did in class only required that the Java devcontainer extension packs in VSCode were installed. Installing that same extension pack is actually the second step for the article’s “Hello World” example. A JDK (Java Development Kit) is vital for running Java in VSCode. With the coding packs and the JDK, Java has been successfully installed onto VSCode.

Creating Source Code Files

The part that fascinated me was creating a source code file. Since the Java coding packs and development kits have now been installed, you can create a file specifically for Java code. This is achieved by choosing a name for your file and adding “.java” to the end of it. VSCode now knows that it is a java file and will recognize any terms and symbols specific to Java that it wouldn’t if it was just a regular text file. Write down code and it won’t take you long to notice that terms like “int”, “for”, “public”, “class”, etc. are colored differently. When you are done writing your code, there should be either a play symbol or a link that says “Run|Debug”. If your code is compilable, the output of your code will be returned in the terminal. 

Interesting Features

VSCode offers many interesting tools that make it easy to search for, test, and edit code among other things. If you have a project in Java or any programming language, it is easy to sort through. On top of that, there are so many extensions such as code spell checkers, debuggers, test runners, and many other tools that make creating code that much easier. Compared to BlueJ and other IDEs I’ve used, this has been the most useful. It took a while to get the hang of, but once I did, I realized how good of a tool VSCode is and can potentially be.

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.

Overview

In order to be able to use someone else’s software for your own software project, you must attain a software license. This license establishes the rights and limitations that you have when using the product owner’s software. Software licenses are attained by licensing agreements, where you sign a contract with the owner of the software to use the patented technology.In that contract contain the rights, responsibilities, and limitations you have as a user. I think if you develop some sort of software, it is crucial that you and your team are recognized as the owners of it, and that outside users don’t use it however they feel like. There are many types of software licenses that have different terms and conditions. An article that I read by Ben Lutkevich went more into depth of what a software license and agreement will usually look like, as well as the different types.

Attaining a License

You are about to sign the licensing agreement to officially be able to use someone else’s software. Here’s what to expect. On it will be basic information about both sides. Your name, your address, contact information, as well as the lending party’s. It will contain when the agreement officially goes into effect, and you are able to use the software. It will contain the duration of how long you are able to use the software. It will include how much you have to pay for the software, how many users are eligible. It will give a disclaimer of warranties, as well as maintenance, upgrades and support. Most importantly, it will include the permissions and limitations on distributing the software, user rights of copying and modifying the software. These licensing agreements may differ depending on the type of software license.

Types of Software Licenses

The most common software licenses you find are Proprietary and FOSS. A proprietary software license is commonly referred to as closed-source. Proprietary licenses do not allow users to freely alter the software. Whereas FOSS (Free and Open-Source Software) is the opposite, where the customer is allowed to use the source code and alter the software. FOSS is commonly referred to as open-source. This is the type of license that we will be using in class. Two other licenses that are familiar are Permissive and Copyleft. Permissive software licenses establish some requirements for distribution or modification of the software, and Copyleft notes that licensed code may be distributed or modified as part of a software application or project if all code involved is distributed under the same license. New products containing old code with a copyleft license have the same restrictions as the old code’s license.

Conclusion

If planning to create a software product, it is a smart idea to establish copyright for it, so you are credited for the work you put in. And if you are using someone else’s product for your own product or project, it is the smart decision to attain a licensing agreement, avoiding any potential lawsuits.

Article URL

https://www.techtarget.com/searchcio/definition/software-license#:~:text=A%20software%20license%20is%20a,the%20software%20without%20violating%20copyrights.

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.

Overview

The objective of any scrum project management framework is to provide structure, fluidity, values and principles when completing a project. But all members of the project must equally pull their weight as well as know their role for the use of scrum to be efficient. A famous saying that relates to this is that “a team is only as good as its weakest link”. This phrase can be applied to basically any team, or group of people pulling for the same cause, in life. I think a scrum team is no different. This article I read by Dave West goes in detail about each role in a scrum team and how they tie in to each other for the team to collectively succeed.

Scrum Team Roles

Previously stated in class, the three roles of a scrum team are: the development team, the product owner, and the scrum master, with each role being just as important as the other. Starting with the development team, the developers are the ones responsible for working on the product. They are the ones bringing the blueprints and requirements, brought from the product owner, to fruition, essentially doing the dirty work of the team. The product owners show them what needs to be done and the deadline by which it needs to be done, and the developers take it from there. They self-organize and make their own decisions on how to complete the task. The development team could be of any occupation from writing, designing, programming, etc. The prime responsibility of a product owner is understanding business requirements and customer feedback. Based on those two things, the product owner is able to set the focus of the team based on meeting deadlines and release dates. It can sometimes be stressful and overwhelming for developers and product owners having to avoid falling behind. This is where scrum masters come in. The scrum master is the overseer, the piece holding everything together. The scrum master must have knowledge in development and product ownership. The development team and the product owner must be able to count on the scrum master for help and support. The scrum master is responsible for the scrum working as one and keeping the values strong in the team, sort of like a coach. The scrum master is usually the most active member of the scrum team.

Conclusion

As previously stated, I think for scrum to work, all members should be on the right pace. The minute that one role falls behind is the minute the framework fails. With much communication, and all members collectively on the right track, scrum is a very strong framework.

Article I Used

https://www.atlassian.com/agile/scrum/roles

From the blog CS@Worcester – William's Blog by William Cordor and used with permission of the author. All other rights reserved by the author.