Hello dear reader. Welcome back to my blog. We talked in the previous blog about Test Driven Deployment. Now it is time to talk about Behavior Driven Deployment. Behavior Driven Deployment is a software development methodology that combines practices from test-driven development and domain-driven design. As we mentioned in the last blog test-driven deployment focuses development on short, cyclical iterations in which (failing) tests are initially created that define the wanted functionality, and only then is actual code written that ensures those previously-failing tests can now pass. Domain-driven design in the other hand, centers on the concept of domain and domain logic. Thus, DDD practices attempt to simplify the terminology in the project scope by focusing and defining everything in the application as real-world objects or concepts that most people are familiar with.
By the combination of TDD and DDD, Behavior Driven Development aims to simplify development trough the use of a common domain-specific language.
As behavior driven development is derived from influenced by TDD, many of the same benefits apply to BDD as well. BDD it reduces regression. When you have a full suite of tests being continually executed, and with new tests always being added, BDD reduces extremely the likelihood of regression bugs popping up as the code is in constant monitoring and testing.
BDD also improves team communication. Since there is a common real-life basis for phrases and terminology when discussing a project, BDD can often improve communication across the entirety of the team.

BDD has also disadvantages like it requires specifications before development and relies on constant outside feedback.

Personally, I like TDD testing better as the code does what you are testing and believe me when I say that the documentation and specifications are bad for a project. There are usually lots of misunderstanding in the specification of a project. It also depends on the project and the company. Thanks for being my reader again.

https://docs.cucumber.io/bdd/overview/

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

https://www.softwaretestinghelp.com/what-is-mutation-testing/

This blog post explains mutation testing with a simple example. Mutation testing is a fault-based testing technique. Variations of a software program are subjected to the test data set to determine the effectiveness of the test set in isolating deviations. The example that this post uses involves a hospital site that lets new users register. The input to the program is the age of the patient. If the age is greater than 14, a general physician is assigned as their main doctor. The example data set for the tester is 14, 15, 0, and 13. The goal is to check if this data set is adequate to identify all possible problems with the code. To achieve this with mutation testing, variations of the program (mutants) must be created. A mutant is nothing more than a deviation that contains a self-seeded fault. Example mutation operators are:

• Arithmetic operator replacement
• Logical connector replacement
• Statement removal
• Relational operator replacement
• Absolute value insertion

Once all the mutants are created they are subjected to the test data set. If the data set kills all mutants, it is effective. If it does not, more or better test data should be used. Each value in the data set does not need to kill all mutants, but all the values combined should kill all mutants.

Some mutants are not useful at all. Mutants to avoid include:

• Syntactically incorrect mutants
• Mutants that do the exact same thing as the original program
• Mutants that can be killed by any data set

The number of mutants can be extremely large, even for a small program. Because of this, a subset of mutants is normally used and the mutants are commonly chosen at random. If there are some mutants alive at the end of the test, it is either an invalid mutant or the data set was inadequate. Mutation testing is a structural, white-box and unit testing method.

This was a useful post because it explained mutation testing with an example that was easy to understand. It also covered all of the important information to know about this testing method. After reading this I feel like I have a much better understanding of what mutation testing is and why it’s used.

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

This week I decided to read a blog post for my blog entry. The blog post I read is titles “These tools will help you write clean code” by Adeel Imran. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

Besides all of the great resources that it gives, a major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have this labeled well. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

https://medium.freecodecamp.org/these-tools-will-help-you-write-clean-code-da4b5401f68e

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

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.

Hello readers, welcome back. This week I will be talking about code reviews and why they are essential to the testing process in computer science. I read  a blog titled “what is code review and why is it so important” by Eugene L. who is a project manager. He begins his blog by talking about how code reviews is a great form of communication between team members and for junior developers, they can become more proficient through this communication and at the same time help improve the code. Although code reviews are used to spot bugs, they have resulted in teams understanding each other better which companies enjoy. Another point brought up in Eugene’s post is that code reviews increase productivity. Because the code will be reviewed by someone else  the developer will be motivated to write better code and make sure its flawless. Finally another reason code reviews are essential is that it helps the developer understand the product better and as a result will be able to communicate better .

This blog had great points and helped me understand why code reviews are  so important to when testing. When it comes to myself, sharing code hasn’t always been a strong suit with me because I tend to get nervous when other people view. I understand that I’m not the best and I understand after reading the blog that one of the ways to improve is by having my peers review my code. Feedback is necessary to have successful code reviews. If you’re working on a project with someone else or a team, you would want to make sure that everyone understands your code and how it effects the product, as a result it will improve the team chemistry. In my recent projects that I have had in my, I try to make sure that my code is understandable. Code reviews are a crucial part in testing and with them, the product will be much better than it would be without it.

From the blog CS@Worcester – Dcanton Blog by dcantonblog 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.