Good day, again dear reader! With classes wrapping up this week and finals starting, I was a little curious at what other testing techniques there were for testing that were not discussed in class. Of course, this lead me to an article called, “The 7 Common Types of Software Testing“. This article had a mix of things discussed in class and some new ones as well.

The first type of test was a black box test, something we discussed in class. In fact, it was among the first we discussed. For a brief review, black box testing is when we are solely concerned with inputs and outputs and we don’t know anything about how the code works or calculates the actual results.

The second test mentioned is white box testing. Another testing method discussed in class. If I remember correctly, it was discussed on the same day as black box testing. Here in white box testing, we can see inside and get a feel for how the program actually works and calculates outputs.

Acceptance testing is a new one to me. Acceptance testing is two-fold. It tests both the system as a whole and it tests the actual requirements of the customer. This test is geared more towards user-friendliness and usability that some of the other tests.

Automated testing is simply any test that has been automated. This I think is more part of other test techniques and not its own technique.

Regression testing is testing the system to ensure that it works the same way as the previous system. This is done in incremental development to ensure that as new parts are added, the original system isn’t broke.

Functional testing is the testing of the system to see if it is functional. The author points out that there is more than just functionality to test for a program and uses that to justify functional testing as its own technique. I’m not quite sure about this decision but I can stomach it for now.

Exploratory testing is testing a system without any actual test cases and exploring the system looking for things that might be wrong or unexpected. Reading the description, it appears to be for testing systems in unusual ways that might not be conventional and testing the boundaries of a system, possibly uncovering bugs that normal testing methods might not find.

Of these new test methods, none of them have really captivated me. Exploratory testing, being honest, sounds a little silly and I can’t really see too many benefits to it. Out of all seven I quite like acceptance testing as it seems to keep the focus shifted to the customer and not just to it the system works or not.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Good day once again my fellow readers! In my readings this week, I discovered something that I had never heard of before, antipatterns. Now that is quite a striking name and it piqued my interest in this subject. So today I will be talking about software development antipatterns, particularly the Blob.

First, let’s discuss what an antipattern even is. An antipattern is simply just an industry term for a common solution to a problem that generates negative consequences. what antipatterns can do for us is twofold. First, they provide a template to help us recognize common problems that can crop up in software development. With this knowledge, we can recognize an antipattern when we see one and identify the cause of it as well. The second part is that antipatterns provide a constructive solution to fix the underlying cause of the antipattern and to implement solutions that can be applied at several different layers in design. Let’s look at the first antipattern I discovered, the Blob.

The Blob is much like its namesake of horror film fame, the Blob. Here one single complex controller class is surrounded by many smaller data classes that merely encapsulate data. In this architecture process is separated from data, thus making this procedural style architecture. Some typical causes of the Blob are lack of object-oriented architecture or lack of any architecture whatsoever. A common occurrence of the Blob is from iterative development where code evolves from proof of concept to a prototype to a functional system. Another cause is a lack of architecture enforcement. But how can we fix this Blob problem?

Refactoring to the rescue! The first step is to locate sets of operations and attributes that directly relate to each other under a common goal. The next step is to locate natural homes from these groups and migrate them to their new homes. We then remove all redundant, indirect associations and migrate associates to derived classes to a common base class. Lastly, remove all transient associations, replacing them if appropriate with type specifiers to attributes and operations arguments.

This discovery of antipatterns for me was quite the find. I don’t know what but I still get a strange feeling when I hear antipatterns. It just sounds so menacing. The Blob was an interesting first antipattern to read as I’m positive that over my past coding projects, many of them would probably fall into this antipattern. It is nice to be aware of these potential issues now, rather than further down my career where it could have a greater impact if I ever do fall into the trap of an antipattern. I definitely plan to read more about these antipatterns and I plan to write about another one next week.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Today I will be looking at an article that examines five basic guidelines when creating a REST API program. I thought that after spending over a month on our final project creating a REST API backend it would be good to review some good practices for creating these REST APIs. The article gives five basic guidelines to follow and a brief background on each of the guidelines. The five guidelines are: name and case conventions for URIs, the different HTTP methods, HTTP headers, query parameters, and status codes. Some of these topics were a refresher from what we’ve already been taught, such as some of the HTTP status codes, and others were new such as the query parameters or case conventions. I especially thought the name and case conventions for the URIs was interesting. I don’t think I have reviewed naming conventions in coding in a couple of years, I usually use camel case for everything since I mostly write in Java. But I have been wondering what was the best practice for endpoints since I remembered code with HTML being more case sensitive. Also, with using different naming schemes instead of just using verbs that describe the method as in Java. I will keep in mind going forward to use the spinal-case method when creating endpoints. The HTTP methods section was fairly straightforward with what I already know, and the use cases for most of them are the same, but it does have a couple of additional methods I haven’t seen before such as HEAD or OPTIONS. The HTTP headers section was interesting, giving definitions and names for the different types of headers you use for different requests. The query parameters section was the most interesting and something that I haven’t come across yet working with REST. The status codes were familiar too, I have mostly used OK, CREATED, and NOT FOUND in my endpoints. Although I will start using NO CONTENT when performing a deletion endpoint instead of just 200-OK, as this seems to be the more proper response code. The same with using a 400 error of BAD REQUEST instead of just giving everything a 404-NOT FOUND error when an invalid request is made or an item is not available. In the future when working with REST I will keep in mind these simple guidelines from this article, especially in regards to case conventions for endpoints and with using appropriate status messages.

Source: https://dzone.com/articles/5-basic-rest-api-design-guidelines

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.

To kick off this week of blogging, the first article of the two I will be writing about this week is titled, “How To Keep Up To Date As A Software Developer”. Like all of the other articles that I have written about on this blog, I just happened to spot this article as I was searching for other articles to write about. Although, this one stood out to me because I recently had an interview for a software development internship near my hometown, and it got me thinking. Maybe I should actually stay up to date in the latest software development trends. Luckily, I happened to stumble upon this piece of coincidental, appropriate-to-my-situation, of writing. So without further adieu, let’s talk about the read of this week.

This article is actually written in the form of an interview. The article leads off with the question, “How do you keep up to date as a web/software developer?”. This was a question that was asked on Quora, which is kind of like Yahoo! Answers, but more credible… I think. Regardless, however, the person who answered this happened to be Mario Peshev, CEO of DevriX. DevriX, if you didn’t know, is a company that handles creating WordPress platforms for other companies. I also didn’t know that, but thankfully the internet exists. I still think the article could have explained that, but what do I know about writing articles. Anyway, Mario goes on to talk about what he does to “keep up to date”. Honestly, it was exactly what I expected it to be, which is disappointing, but I don’t know what I expected. He provides 12 ways to keep up to date, and they are exactly what’d you’d expect. (Collegues, Internet, Working, Social Media, etc.) He did mention books which is an obvious answer, but he mention the Gang of Four book, and that immediately caught my attention. It made me feel all professional because we used that book in class, so, in the end, Mario and I are basically the same, except he makes a lot more money than I do.

This article would have to rank low on the list of articles I read because it was predictable. I’m not saying that the article was bad, but obviously, books and the internet are good ways to keep up to date. Granted, I don’t know why I expected there to be some magical new way to keep up to date that only Mario knew, so I guess that is my fault. Overall, this was a good read, but you already know how to do this, so you are better off finding another article.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

For this week’s post for software architecture, I decided to explore pursuing it as a career. I have focused several of my posts in this blog to going into a career for software architecture and quality assurance, but software development is very appealing to me as well.

Although I have found this class more difficult than the quality assurance class, I find the work we have done in this class very satisfying, and I would like to do something like this in my career.

I found an article from “Lifehacker,” where they interviewed a software architect Harrison Ambs on what it was like to be a software architect. It focused less on what a software architect is, and more gave general career advice for someone in the industry.

The final question in the interview said, “What advice would you give to those aspiring to join your profession?” He gave a paragraph with some good advice. (Starting with, “Always be willing to learn something even if you know you’ll be terrible at.”) However, I wish more of the article expanded on this and made this more of the focus of the interview.

In one of the answers, he said he worked around 45 hours a week. There were a lot of answers that were like this, and these sort of things are good to know for seeing what a career in the field would be. However, they were good to know, but these didn’t seem like the most important things that the article could be focusing on

I suppose they didn’t want to flood the article with jargon that someone who was outside the discipline or was just starting wouldn’t know, but I think they missed a great opportunity to inspire someone to become a great architect.

There was some good information in there, though. He said he is always learning from blogs and newsletters of “as many individual app developers as possible because these people are honed like a samurai blade when it comes to software development.”

That is good to follow through on as I am pursuing my craft. It is always good to be continuously learning and growing your skills and mindset. This is something that these blogs have made me start doing, and it is something that I would like to continue to develop.

https://lifehacker.com/career-spotlight-what-i-do-as-a-software-architect-1699203274

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

https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

A test double is a generic term used for objects that look and behave like their production equivalents, but are actually simplified. Test doubles are used to reduce complexity and verify code independently from the rest of the system. There are many different types of test doubles, and misunderstanding or mixing them will make fragile tests. This blog post discusses three different variations of testing doubles: fakes, stubs, and mocks.

Fakes are objects that have working implementations different from production ones. An example is using an in-memory data repository instead of accessing a database. The benefit of this is that integration tests can be carried out without performing the time-consuming process of starting up and requesting information from a database.

A stub is an object that holds predefined data and answers calls during tests with this data. Stubs are used when we don’t want to involve objects that would answer with real data. For example, if there is an object that needs to get data from a database to respond to a method call, a stub can be defined with the data that should be returned instead of using the real object. Stubs are preferred for methods that return some result and do not change the state of the system because it allows verification of a method’s return value.

Mocks are used for methods that change the system state but don’t return any value. Mock objects register the calls that they receive. Assertions are used in testing to verify that all expected actions were performed. Mocks are commonly used when we don’t want to invoke production code or when there is no easy way to verify that the intended code was executed.

This blog was a good overview of the differences between fakes, mocks, and stubs. Reading this helped to solidify what I learned in class and gave me a better understanding of when each test double would be used. I especially liked the images and code examples used as they made the idea behind each one easy to understand. Overall this was a well-written and useful blog post that gave me a deeper understanding of material learned in class.

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

Today I will be talking about testing software! More particularly, testing by using dummys! So what exactly is a dummy and why do we use it in testing. Dummys are objects that are created for the purpose of testing but are actually never used. Think about it like a mannequin. The mannequin displays the clothes as how they would look on a human, but the mannequin is not actually a functional human, and does not actually use the clothes. Its only job is to make sure the clothes look (or function for the sake of testing) correctly. According to this blog by Tom Winter, “How our test data generator makes fake data look real”,  our test generator makes fake data look real for the purpose of testing our code. Why would we ever want to test fake data? The easy answer is this: sometimes we do not have all the data or all the code finished, and we want to test our code without having to play the waiting game. Sometimes it is even impossible to test our own code without dummys because we do not have access to the actually data. So we use these dummy objects to play the role of the real data (which we do not actually have access to, remember?) in order to test our code to ensure it functions properly.

Testing with dummy objects is something we have been doing in my software program at school, and I happen to find it very useful in the sense that I do not actually need the data to make sure my code works. Not only does this help pick up testing efficiency,  but it cuts down on the overall wait-time between developers and getting their product out. On the flipside of things, if another developer was waiting for me to finish my code before testing, they could use a dummy to test their code instead of rushing me to finish, which could possibly lead to me making mistakes and end up slowing down the entire development process. I enjoy being able to test right away, and using dummys can help with this. I hope to continue using dummy testing in the future, as it is an easy and very effective method of testing!

Here’s the link: https://medium.freecodecamp.org/how-our-test-data-generator-makes-fake-data-look-real-ace01c5bde4a

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.