CS 443 has taught me many things: how to test code, the different ways to test code, collaboration among peers, what is possible/not possible in Java, mockito, the list goes on. What it has not taught me is how code is actually tested in the field professionally; what should I expect to do or know if I were to shift towards the QA Engineer path?

‘A Day in the Life of a QA Engineer’ by AJ Larson talks about what he does in a professional setting and I compared it to the daily tasks we performed in class and it seems it is not completely opposite. He starts off by comparing software developers to QA engineers and stating that it is not too different; some companies even combine the two into one where you are a dev and a tester. He talks about how the team communicates; telling each other where they are in the project, what their plan is and if they have been encountering any problems. I guess in a way we have been doing that in class.

Onto the more important part of this blog is where he talks about testing ‘stuff’. He spends his time running manual tests and when he encounters a failed test how he goes about it. I learned that communication is key in both school and professional work environment; pretty much anywhere there is teamwork there must be communication.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

In the final exam, there were a few questions on mutation testing which I was very unfamiliar with so I decided to look into posts/blogs about mutation testing. One interesting blog I came across was written by James White – ‘Mutation Testing – Who will test the tests themselves?’.

The very first sentenced stated “this is aimed at people who are not familiar with mutation testing” and it was all over from there; I had been sucked into the article since I had no idea what mutation testing really was.

White starts off by describing what mutation testing really is and his definition was “Very simply mutation testing is a way of testing the quality of your tests by introducing changes into your code and seeing if your test suite detects them”. Very straight forward. He then gives an example written in java and a scenario seen below:

private static final int MARGARINE_WEIGHT = 100;
private static final int COCOA_WEIGHT = 25;
private static final int EGG_COUNT = 2;
private static final int ORANGE_JUICE_VOLUME = 15;

Cake createCake(CakeType cakeType) {
Cake cake = new Cake();
cake.setMargarine(MARGARINE_WEIGHT);
cake.setSugar(MARGARINE_WEIGHT);
cake.setEggs(EGG_COUNT);
if (CakeType.CHOCOLATE.equals(cakeType)) {
cake.setFlour(MARGARINE_WEIGHT - COCOA_WEIGHT);
cake.setCocoa(COCOA_WEIGHT);
} else {
cake.setFlour(MARGARINE_WEIGHT);
if (CakeType.ORANGE.equals(cakeType)) {
cake.setOrangeJuice(ORANGE_JUICE_VOLUME);
}
}
return cake;
}

As well as different test cases:

@Test
public void canCreateVictoriaSponge() {
Cake actual = testee.createCake(CakeType.VICTORIA_SPONGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(0, actual.getOrangeJuice());
}

@Test
public void canCreateOrangeCake() {
Cake actual = testee.createCake(CakeType.ORANGE);
assertEquals(100, actual.getMargarine());
assertEquals(100, actual.getFlour());
assertEquals(100, actual.getSugar());
assertEquals(2, actual.getEggs());
assertEquals(15, actual.getOrangeJuice());
}

He then shows us the results of his tests as well as his mutation tests. So I learned that mutation testing works on the principle that since the test code is there to ensure that the code works, if mutating a test, at least one test should fail. Mutation killed means all your tests pass and mutation survived indicates that the mutation survived and there is a potential area where a bug could arise.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Towards the end of the semester we were working more intensively in group settings and even increased the number of individuals in our group which required greater collaboration among peers. I recently came across a post ‘Code Review: The Unit of Work should be a Single Commit’ by Paul Hammant. In this blog Hammant talks about the benefits of Code Review and how the end result is significant change in the way the program was written.

Some of the benefits he listed was:

– Two pairs of eyes catch more bugs (which saves hours of debugging if fixed early)
– Enforce coding standards, style guides (keeps overall readability & code quality high)
– Mentoring of new developers (learning from mistakes without breaking stuff)
– Establish trust relationships
– A good alternative to pair programming.

Our last few classes we as a group came across all of these aspects and more. We worked collectively as a team code reviewing some program and found that we listed many similar mistakes. Another important point he makes is that there is only so many times something is modified in review before it is considered ‘done’.

Although Hammant talks about reviewing code over Git and we did ours as a group in person the idea remains the same. Some steps he talked about were to lock a commit for the duration of each review and also how to move forward with which review change when two individuals have different points of view. I found that this article was relatable to our experience.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Today, in this final post of the semester for CS-343 I will be examining the JPA architecture. This is something I have been curious about after browsing articles on DZone for the past couple of weeks and seeing this topic pop up a lot, luckily they made a good introduction post this week. From the article: “The Java Persistence API is the Java standard for mapping Java objects to a relational database”, this is something that I have been wondering how to do since we started working with the REST APIs and our projects that have been using Java HashMaps for makeshift databases instead of something more permanent like SQL. This article briefly introduces and explains the functionality of the six key parts of the architecture for JPA. The article gives a diagram for these six units and the multiplicity of their relationships. The article then gives a simple example of mapping a simple Java POJO Student class into data for a database, using the student ID as the primary key. I was surprised at how easy this translation was, all it includes is a couple of tags for columns above the instance variables that designate the database column, and which one is the primary key to generate in the database. The article then creates an application class that uses the various entity classes to store a newly created student into a database. I liked the simplicity of the article as most introductory articles are on this website for what are advanced programming topics, but my biggest criticism is that this article has brief definitions for many of the elements of JPA and then links to an external site that further elaborates on them. I wished that the author put a bit more time and consolidated all of this information into one article for this site, instead of having a bunch of separate webpages on his own website. I also wish he showed in this post getting data from the database and translating it back into Java and performing manipulations on this data with methods. Overall it was a good introduction to a very useful topic and one that I would like to further look at. Going forward, I am much in favor of using this way of storing data as opposed to simple Java in-memory databases for entire applications like we did in our projects.

Source: https://dzone.com/articles/introduction-to-jpa-architecture

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

Today I am looking at another design pattern. This one is the command design pattern, which is yet another Gang of Four design. They classify it as a behavioral pattern with object as the scope (GoF 223). I wanted to explore this one as reading through the different pattern descriptions in the Gang of Four book, this peaked my interested by its ability to separate requests from objects. The article gives a good summary of the idea of the pattern with a real-life example of a restaurant with a server taking an order from a customer and handing it off to a chef. It then further breaks down the pattern with the usual UML diagram and a helpful sequence diagram that shows the order in which the classes perform the pattern. I found this sequence diagram, along with the comments in the example program with code that show which class matches with which part of the diagrams really useful in this example, as the pattern goes through a couple of classes just to call a basic function on a simple object. Although this pattern does seem complex at first, it has a nice simplicity once you understand what all the classes are doing, and once you get the base created adding more functions is as simple as adding more command classes. The article then creates a simple example with Java of the command pattern using the various classes to switch a light bulb object on and off. I do like the idea of the pattern and its particular implementation in this example. It nicely breaks down requests into their own separate command objects that gives much greater control over requests across a program. I agree that the ability this pattern gives to create a log of function calls and add an ability to undo all functions called on an object is very helpful. I also agree with the author that it can get messy if you have a lot of functions that need to be implemented. As this pattern calls for a separate command class to be made for each function or method performed on an object, this can quickly add up depending on how many methods you need in your program. In the future, I will definitely remember this pattern and its useful ability to separate commands from the objects it performs them on.

Source: https://dzone.com/articles/design-patterns-command

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

For my last blog for this class — Software Quality Assurance and Testing — I decided to look at what I could find about the subject in the news. After searching around, I found an article from Forbes that came out only a few days ago — December 17. The article was titled “AI In Software Testing: Will A Bot Steal Your Spot?”

My first impression before I read the article was, “Of course not! There will always be people whose job it is to test software.” Software is growing to touch every corner of our lives, and even if AI is incorporated, I would think it would be unlikely that they would entirely, or even partially, replace testers.

Halfway through the article, the author confirmed my skepticism by saying, “While it’s unlikely the testers will be wiped out, I think machine learning and other branches of AI will significantly alter the way software testing is conducted.”

The article seems to have a misleading title. The article goes on to give several examples of how robots will be useful for people, but they will be still be implemented by people, whose jobs are still be there, even with the robots. It didn’t even hint even some jobs would be lost. It just said the job would look different. Seems pretty obvious that new tools will come out that will change how the work is done. That is true for most all industries.

The article might as well been titled “Sharks in the Ocean: Will You Be Eaten When You Go Swimming?” And then once you read it says “probably not.” This is link bait at it’s finest. Have a sensationalized title for people to click on, and then say, “It’s not going to happen.” It would be one thing if it were titled something different.

However, at least I sighed a breath of relief when I read what the article concluded. I would hate for something that I have wanted to pursue as a career be automated before I even graduate.

I’m sure that many parts of the computer science industry that will change dramatically over my career. I hope like most people that I will always be able to find work, but I think that the field is going to be fairly stable for a long time. However, I’m sure there will be no shortage of headlines that have similar titles — “Is your job in jeopardy?” I also think that the article contents will usually say that it’s not.  I do think it’s a good idea to keep alert to changes in the industry because no career or company is invulnerable.

Work Cited:

https://www.forbes.com/sites/forbestechcouncil/2018/12/17/ai-in-software-testing-will-a-bot-steal-your-spot/#996553136710

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

AngularJS is an open source web application framework. It was originally developed in 2009 by Misko Hevery and Adam Abrons. It is now maintained by Google. Its latest version is 1.2.21. AngularJS is a structural framework for dynamic web applications. It lets you use HTML as your template language and lets you extend HTML’s syntax to express your application components clearly and succinctly. Its data binding and dependency injection eliminate much of the code you currently have to write. And it all happens within the browser, making it an ideal partner with any server technology.

GENERAL FEATURES:

• AngularJS is an efficient framework that can create Rich Internet Applications (RIA).
• AngularJS provides developers an option to write client-side applications using JavaScript in a clean Model View Controller (MVC) way.
• Applications written in AngularJS are cross-browser compliant. AngularJS automatically handles JavaScript code suitable for each browser.
• AngularJS is open source, completely free, and used by thousands of developers around the world. It is licensed under the Apache license version 2.0.

Overall, AngularJS is a framework to build large scale, high-performance, and easy to maintain web applications.

CODE FEATURES:

Data Binding – It is the automatic synchronization of data between model and view components.

Scope – These are objects that refer to the model. They act as a glue between controller and view.

Controller – These are JavaScript functions bound to a particular scope.

Services – AngularJS comes with several built-in services such as $http to make an XML Http Requests. These are singleton objects which are instantiated only once in app.

Filters – These select a subset of items from an array and returns a new array.

Directives – Directives are markers on DOM elements such as elements, attributes, CSS, and more. These can be used to create custom HTML tags that serve as new, custom widgets. AngularJS built-in directives such as ngBind, ngModel, etc.

Templates – These are the rendered view with information from the controller and model. These can be a single file (such as index.html) r multiple views in one page using partials.

Routing – It is concept of switching views.

Deep Linking – deep linking allows to encode the state of application in the URL so that it can be bookmarked. The application can then be restored from the URL to the same state.

Dependency Injection – AngularJS has a built-in dependency injection subsystem that helps the developer to create, understand, and test the applications easily.

ADVANTAGES OF ANGULARJS:

• It provides the capability to create Single Page Application in a very clean and maintainable way.
• It provides data binding capability to HTML. Thus, it gives user a rich and responsive experience.
• AngularJS code is unit testable.
• AngularJS uses dependency injection and make use of separation of concerns.
• AngularJS provides reusable components.
• With AngularJS, the developers can achieve more functionality with short code.
• In AngularJS, views are pure html pages, and controllers written in JavaScript do the business processing.

DISADVANATAGES OF ANGULARJS:

Not Secure – Being JavaScript only framework, application written in AngularJS are not safe. Server-side authentication and authorization is must to keep an application secure.

Not degradable – If the user of your application disables JavaScript, then nothing would be visible, except the basic page.

References:

https://angularjs.org/

https://en.wikipedia.org/wiki/AngularJS

https://www.w3schools.com/angular/angular_intro.asp

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