Category Archives: Week 12

Design Patterns: The Builder Pattern

In this blog post, Riaan Nel goes over an example of the Builder Pattern, a creational pattern used to create and configure objects. The following example is from Effective Java by Joshua Bloch.

The Problem

In this example, we are part of a Java team working on software for a bank. We need a way to represent banks accounts.

BankAccount.java

public class BankAccount {
    private long accountNumber;
    private String owner;
    private String branch;
    private double balance;
    private double interestRate;

    public BankAccount(long accountNumber, 
                       String owner,
                       String branch,
                       double balance,
                       double interestRate) 
       {
        this.accountNumber = accountNumber;
        this.owner = owner;
        this.branch = branch;
        this.balance = balance;
        this.interestRate = interestRate;
   }
    //Getters and setters omitted for brevity.
}

We run into two problems in the about code:

  • Too many constructor arguments
  • Incorrect object state

The Pattern

The builder pattern “allows us to write readable, understandable code to set up complex objects. It is often implemented with a fluent interface, which you may have seen in tools like Apache Camel or Hamcrest.” The builder will


public class BankAccount {
    public static class Builder {
        private long accountNumber; 
        private String owner;
        private String branch;
        private double balance;
        private double interestRate;

        public Builder(long accountNumber) {
            this.accountNumber = accountNumber;
        }

        public Builder withOwner(String owner){
            this.owner = owner;
            return this; 
        }

        public Builder atBranch(String branch){
            this.branch = branch;
            return this;
        }

        public Builder openingBalance(double balance){
            this.balance = balance;
            return this;
        }

        public Builder atRate(double interestRate){
            this.interestRate = interestRate;
            return this;
        }

        public BankAccount build(){
            BankAccount account = new BankAccount(); 
            account.accountNumber = this.accountNumber;
            account.owner = this.owner;
            account.branch = this.branch;
            account.balance = this.balance;
            account.interestRate = this.interestRate;
            return account;
        }
    }
    //Fields omitted for brevity.
    private BankAccount() {
        //Constructor is now private.
    }
    //Getters and setters omitted for brevity.
}

We can create new account with the following code:


BankAccount account = new BankAccount.Builder(1234L)
            .withOwner("Marge")
            .atBranch("Springfield")
            .openingBalance(100)
            .atRate(2.5)
            .build();
BankAccount anotherAccount = new BankAccount.Builder(4567L)
            .withOwner("Homer")
            .atBranch("Springfield")
            .openingBalance(100)
            .atRate(2.5)
            .build();

This makes code clearer and more verbose. Using the Builder pattern is a good solution if you find yourself having to add more and more parameters to the constructor resulting in error-prone and hard to read code. I chose this resource because I wanted to learn more about design patterns, and I did not know much about this pattern. I learned how the Builder pattern can help simplify code that may get too complex and hard to read. The content of the post is good quality and the example used was simple and easy to understand, making learning how the Builder pattern works easier. I plan to use this information when in my professional career whenever the Builder pattern would be the best solution.

The post Design Patterns: The Builder Pattern appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Blog #8

Soft Qual, Assur & Test

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

HTML Elements and Semantics

In the second lesson of Shay Howe’s HTML and CSS tutorial, he begins going in more depth about HTML by showing which HTML elements are best used to display different types of content, how they’re visually displayed on a web page, as well as what different elements mean semantically.

Throughout the tutorial, Howe describes several different HTML elements and explains what their purpose is. He also displays a live demo of his examples which is very useful in understanding exactly what each element looks like visually. The list of elements that he describes and their purposes are as follows:

  • <div>: division – a block-level element that is commonly used to identify large groupings of content; helps to build a web page’s layout and design.
  • <span> – an inline-level element commonly used to identify smaller groupings of text within a block-level element.
  • <h1-h6>: heading – block-level elements with six different levels. These help to quickly break up content and establish hierarchy.
  • <p>: paragraph – blocks of text visually separated from adjacent blocks (i.e. vertical blank space, first-line indentation, etc.)
  • <b>: bold – stylistically offsets text.
  • <strong> – places a strong importance on text by bolding it.
  • <i>: italicize – conveys text in an alternative voice or tone by slanting it.
  • <em>: emphasis – places a stressed emphasis on text.

HTML5 introduced new structurally based elements in order to give meaning to the organization of our pages and improve structural semantics:

  • <header> – used to identify the top of a page, article, section, etc.
  • <nav>: navigation – identifies a section of major navigational links on a page.
  • <article> – used to identify a section of independent, self-contained content that may be independently distributed or reused.
  • <section> – used to identify a thematic grouping of content, usually includes a heading.
  • <aside> – holds content that is related to the main content around it, but not central to the flow of it.
  • <footer> – identifies the closing or end of a page, article, section, etc.

Howe emphasizes the importance of understanding the semantic difference of elements. For example, even though the elements <strong> and <b> both create the same bold text effect, they’re semantically different. The <strong> element is used to give strong importance to text while the <b> element simply stylistically offsets text.

The reason I’m writing about this topic because it’s very relevant to our final project. Prior to reading this I hadn’t even considered the semantics of elements. Also it’s useful to understand how to use each element. In the future I’ll be able to use what I learned to better organize pages and improve its structural semantics. I’ll also be able to apply this to my final project, so this lesson has been very useful to me.

Source: https://learn.shayhowe.com/html-css/getting-to-know-html/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Engineering Productivity

This post is about a new development in software testing, a possible evolution that makes so much sense logically to me I can’t believe I didn’t draw the conclusion earlier in my posts about Test Ops.

Google has recently (ok, more like earlier in the year) renamed their Testing Automation Conference into the Engineering Productivity conference. They also did the same with their team.

And this instantly went back to all the Test Ops posts I’ve been reading.

All of them showed the natural progression of simple testing into something wholly devoted to increasing productivity itself of an engineering project. Continuous Improvement, Testing and Development. Testing not only if a product works but if it is working effectively or not. Testing and Quality Assurance are simply the beginning of using software to ensure increased productivity of software engineering projects.

The essence of it is to let the developers themselves handle the tasks of making sure the code works and is of good quality. This means that they will be making tests for their own code. Obviously, just doing this would not be very effective, as developers might not be great at testing. This is why a new task for the Engineering Productivity team is provide guidance and tools to developers to help them more effectively produce effective tests with good code coverage and that will make sure the performance is reasonable. By doing this, the responsibilities of the team are lowered and they can take on more responsibilities in terms of aiding with Continuous Development, and using big data techniques to test the how effective features are at keeping users (for projects where this is applicable) so developers know where to steer productivity.

Of course, there needs to be flexibility. Focusing on testing in the beginning seems to be very effective, leading to there being much less issues down the road. So the team focuses their time on things like pending time on IDE plugins, code coverage, and effective code review. After release, the team can shift over to Testing in Production tasks, especially when features or updates start development. A responsibility the team always has is making sure there are no testing bottlenecks. If a test takes too long, people will stop running them altogether at some point.

This is really a formalization of all the other topics I’ve posted on. Seeing the evolution of a dedicated testing team, the blending between developer and tester, and finally leading to the testing team becoming a team focused not only on testing but increasing production in general is quite fascinating. In a way, the testing team was always about increasing productivity, and formalizing it has made that apparent.

Original Post: http://www.awesome-testing.com/2017/07/testops-5-engineering-productivity.html#more

From the blog CS@Worcester – Fu&#039;s Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Blog #8 – “Bloaters”

Another programming term I learned about this week is “Bloaters” which are code, methods, and classes that have increased to such big proportions that they are difficult to work with. This is part of a section of code that “smells”, which doesn’t literally smell, but it means that this type of code stinks. When it comes to bloaters, these “smells” do not come up right away, but they accumulate over time as the program evolves.

https://sourcemaking.com/refactoring/smells/bloaters

The blog “Source Making” goes in-depth with Bloaters and I like this blog because it breaks down the types of Bloaters and explains what they are, what causes them, and how to fix them in a way that’s easy to understand. The blog lists a few types of Bloaters.

  • Long Method
  • Large Class
  • Primitive Obsession
  • Long Parameter List
  • Data Clumps

Long Methods are methods with too many lines of code. The rule of thumb given by this blog is that if a method has more than ten lines of code, it should be reconsidered. A solution given by the blog is that if you feel the need to comment on something inside a method, you should take the code out and put it into a new method instead.

Large Class is a class that contains too many fields/methods/lines of code. Classes usually start small but get bloated as the program grows. If a class is wearing too many “hats”, then you should think about splitting them up.

Primitive Obsession is the use of primitives instead of small objects for simple tasks, the use of constants for coding information, and the use of string constants as field names for use in data arrays. Like many other smells, primitive obsessions are born in moments of weakness but become a problem later on. The blog suggests that if you have a large variety of primitive fields, it could be possible to logically group some of them into their own class, or move the behavior associated with the data into the class too.

Long Parameter Lists are more than three or four parameters for a method. To fix this, check what values are passed to parameters, if some of the arguments are just results of method calls of another object, you should replace the parameters with a method call.

Data Clumps are different parts of the code that contain identical groups of variables and should be turned into their own classes. This can be caused by copying and pasting a lot of code, and if you see repeating data, the blog suggests using the Extract Class to move data fields to their own class.

This blog gave me a great understanding of types of code smells, like the Bloater, with multiple examples of bloaters that many of us may encounter or even create while coding. This is a good way to see if you’re practicing bad coding habits and how to fix them to make your code more concise and to make your programs run better.

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

Software Technical Reviews

Last week we covered software technical reviews and we got to experience it with in a group of five developers. There are a few different types of reviews like walkthroughs, technical inspection, and audits. Walkthroughs are informal and often between colleagues, where technical inspections are conducted formally by a carefully selected team. As for Audits, that is typically conducted by an external group like a software quality assurance group, a project group or outside agency whose main concern is conformance with expectations. This is an important topic because in software development, we will always be in teams where we work with each other’s code. Therefore, technical reviews allow a developer to receive feedback on how to improve their code’s style, structure, or even how to write better comments. Although we did not have an in depth practice with the technical review, we were able to fill in the roles in a review. I was an individual reviewer, my job was to be technically inclined and not have any bias or personal agenda on the work product. The goal was to find issues in the code and document them by location, line number, item type, and severity on our individual reviewer spreadsheet. Even though technical reviews are supposed to be brief, I had to run the code and understand the SirTommy solitaire game to provide a better feedback. I did find a few issues; our group came up with twenty-four issues in total.

Software technical reviews are beneficial in many areas, however as a recent college graduate, it is important to understand that reviews will help us improve our code and conform to company standards. Every company may have a different standard on how they structure their code, so I can see how reviews are extremely useful when It comes to training new personnel. Personally, after college, I hope the company I work for will conduct reviews, so I can quickly adapt to their coding standards. This will not only lead to improvement, but also strengthen the communication among all developers.

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

Over-reliance on testing considered harmful!

This week i chose a blog that talks about some of the harmful things about over-reliance on testing, the article can be found Here. Through out the semester i have read several blogs were they talk about the many positives of software testing. I chose this blog because i thought that it would be interesting to have another perspective on the topic.

The main point that this article is trying to get across is that while testing is great focusing extensively on testing is not the right strategy for ensuring high quality software. Testing specifications are great tool but not necessarily the best for finding bugs. The test cases specifications that are given to testers are often a great way to figure out what the client needs and to set up those boundaries and documentation. However this might not always lead to discovering more bugs in our code. In this article they give an example of two teams one which was given clear test specifications and the other which was told to just simply test and make the code the best they could. The team which did not have the testing specifications found more bugs than the team that did.

There is no perfect solution when it comes to software development, but there are somethings that have been shown to be effective.  This is old fashioned manual review techniques such as peer-reviews, inspections, code and design walk-throughs. Manual reviews have many positives, the first being that on top of finding actual bugs they can also find potential and latent bugs. Additionally these types of reviews can also be used to find design flaws and weak spots in your code that might be harder to find later on. The downside to manual reviews are that they are effort intensive which can be make it harder to implement under a time constraint. To combat this the blog recommends using static analyzers as part of the Development life cycle. These tools are able to find bugs that are hard to detect with testing or even manual reviews, by using modern and advanced techniques such as model checking, abstract interpretation, and program querying. One downside to static analyses software is that it is costly, however it usually has a high return on investment.

In conclusion when testing is combined with manual reviews, and a static analysis tool in the development life cycle this can lead to high quality software. I found this article to be very interesting all the way through. It touched on some of the same things we saw in class when we did our own code reviews. It was cool to see how a lot of the different things we have been doing through out the semester can come together to result in better software development. Lastly i found the static analyzer portion of the article to be very interesting, although i am not one hundred percent sure how they work still. The article did not go into great detail on the specifics with how static analyses software works , and this is something i would like to look into more in the future as the benefits seem to be great.

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

Blog #7 – “The Blob”

This week, I am writing about the first Antipattern that I’ve learned about, which is called “The Blob.” I learned about this Antipattern from the website “Source Making.” And I like this blog’s explanation of The Blob because it breaks everything about it down into different sections, making it easy to understand.

https://sourcemaking.com/antipatterns/the-blob

The blog begins with some background to make the idea of The Blob Antipattern easier to understand by first describing the movie of the same name, where an alien would grow as it consumed things, which is a good analogy for the Blob AntiPattern because it has been known to consume entire object-oriented architectures.

The blog then goes on to explain that The Blob is found in designs where one class monopolizes the processing, which means that the majority of the responsibilities are allocated to a single class. Because of this, the code is procedural-style rather than object-oriented architectures.

The next section of the blog describes symptoms and consequences of the Blob. Which include: a single class with a large number of attributes, operations, or both. The blog explains that a class with 60 or more attributes and operations usually indicates the presence of the Blob. A disparate collection of unrelated attributes and operations encapsulated in a single class. A single controller class with associated simple, data-object classes. And an absence of object-oriented design. A program main loop inside the Blob class associated with relatively passive data objects, the single controller class nearly encapsulates the application’s entire functionality.

The blog then goes on to explain typical causes of The Blob AntiPattern which include: lack of an object-oriented architecture, lack of architecture enforcement, too limited intervention, and a specified disaster.

A solution for the Blob AntiPattern offered by the blog is a form of refactoring. The key is to move behavior away from the blog and to reallocate behaviors to some of the encapsulated data objects in a way that makes those objects more capable and the Blob less complex.

So from this blog, I learned about my first AntiPattern, The Blob. Like the movie of the same name, a Blob AntiPattern is where one class monopolizes the processing of the other classes in a program. It gives too much responsibility to the single class and leaves not much else for the rest of the classes to do. This is bad practice, and to fix this AntiPattern you should refactor your code by taking away some of the responsibilities from the Blob and delegate it evenly to the other classes to make the program more equal in processing.

 

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

HTML Elements and Semantics

In the second lesson of Shay Howe’s HTML and CSS tutorial, he begins going in more depth about HTML by showing which HTML elements are best used to display different types of content, how they’re visually displayed on a web page, as well as what different elements mean semantically.

Throughout the tutorial, Howe describes several different HTML elements and explains what their purpose is. He also displays a live demo of his examples which is very useful in understanding exactly what each element looks like visually. The list of elements that he describes and their purposes are as follows:

  • <div>: division – a block-level element that is commonly used to identify large groupings of content; helps to build a web page’s layout and design.
  • <span> – an inline-level element commonly used to identify smaller groupings of text within a block-level element.
  • <h1-h6>: heading – block-level elements with six different levels. These help to quickly break up content and establish hierarchy.
  • <p>: paragraph – blocks of text visually separated from adjacent blocks (i.e. vertical blank space, first-line indentation, etc.)
  • <b>: bold – stylistically offsets text.
  • <strong> – places a strong importance on text by bolding it.
  • <i>: italicize – conveys text in an alternative voice or tone by slanting it.
  • <em>: emphasis – places a stressed emphasis on text.

HTML5 introduced new structurally based elements in order to give meaning to the organization of our pages and improve structural semantics:

  • <header> – used to identify the top of a page, article, section, etc.
  • <nav>: navigation – identifies a section of major navigational links on a page.
  • <article> – used to identify a section of independent, self-contained content that may be independently distributed or reused.
  • <section> – used to identify a thematic grouping of content, usually includes a heading.
  • <aside> – holds content that is related to the main content around it, but not central to the flow of it.
  • <footer> – identifies the closing or end of a page, article, section, etc.

Howe emphasizes the importance of understanding the semantic difference of elements. For example, even though the elements <strong> and <b> both create the same bold text effect, they’re semantically different. The <strong> element is used to give strong importance to text while the <b> element simply stylistically offsets text.

The reason I’m writing about this topic because it’s very relevant to our final project. Prior to reading this I hadn’t even considered the semantics of elements. Also it’s useful to understand how to use each element. In the future I’ll be able to use what I learned to better organize pages and improve its structural semantics. I’ll also be able to apply this to my final project, so this lesson has been very useful to me.

Source: https://learn.shayhowe.com/html-css/getting-to-know-html/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Post #16

I found an article on SoftwareTestingHelp.com entitled “Web Testing: A Complete guide about testing web applications” and I thought it would be relevant to review and summarize it in a blog post.  I have been working on my first true web application, recently, and realized that I may get to a point in its development where I want to conduct tests on it.  During my search for resources on the subject, I found many articles that covered a good portion of web application testing, but this guide was the most comprehensive and helpful, in my opinion.  Having read it, I feel that I will be able to conduct more inclusive and thorough tests of our application, if necessary.

This guide covers the 6 major web testing methods:

  • Functionality Testing
  • Usability Testing
  • Interface Testing
  • Compatability Testing
  • Performance Testing
  • Security Testing

Functionality Testing
Testing links, forms, cookies, browser optimization, databases, etc.

  • Links – Test for external and internal links, links used to send email/messages from users; Check for unlinked pages, broken links, etc.
  • Forms – Test for validations on each field, default values, wrong inputs, options to create/view/delete/modify forms, etc.
  • Cookies – Test for enabled/disable options, encryption, session cookies storing session information after they end, deletion of cookies, etc.
  • Browser Optimization – Test for syntax errors, crawlability, etc.
  • Databases – Test for data integrity, errors while you edit/delete/modify databases, correct execution of queries,  etc.

Usability Testing
Testing navigation, conent, user assistance, etc.

  • Navigation – Test for ease of use, consistency, etc.
  • Content – Check for spelling errors, broken in-text links, proper format of text and images, etc.
  • User assistance – Check for all links on sitemap, test search options and help files, etc.

Interface Testing
Testing the application server and database server interfaces.

  • Check that interactions between servers are executed properly, what happens if a user interrupts one of these interactions, what happens if a connection to the server is reset during an interaction, etc.

Compatibility Testing

  • Testing the compatibility of the program to different browsers, operating systems, mobile operating systems, and printers.

Performance Testing

  • Testing the performance of the application on different internet connections with different amounts of traffic.

Security Testing
Testing the web security of the application.

  • Test for internal pages opening without being logged in, reaction to invalid login inputs, effective CAPTCHA, all transactions/errors/security breach attempts should get logged in log files somewhere on the web server, etc.

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