We’re approaching week four in the semester and getting into the processes of testing code. Prior to taking this course, I’ve tested code typically with random input, ad-hoc style. But I am now learning new testing methods as well, which are more systematic and cover larger ranges of potential case failures. That being said, I would like to talk about unit testing in general, and why it is so important.

We do unit testing because we want to ensure that our code works. Sometimes it can be frustrating when we can’t get our code to do what we want it to do. We need to do thorough testing to weed out these problems. For instance, perhaps our code works sometimes, but not always, and we have no idea why.

It can be disheartening when spending hours trying to fix something in your code which seems to magically work for some inputs, but then crashes on others. It seems that simply entering a finite and/or random number of test cases, or simply not running tests frequent enough, we may not ever find out why our code only works sometimes, but not always.

Now that I’ve discussed a few reasons why I feel that unit testing is important, I would like to share a blog that I found on the topic as well.

The Green Machine (TGM): 5 Reasons Why Unit Testing is fun–and Important

As the title suggests, TGM provides additional clarification as to why testing code is an essential part of programming. He also emphasizes that unit testing is fun as well, for a variety of reasons.

For instance, TGM states that unit testing can be rewarding in the sense that “we can execute our code right away and know that it works.” Since one of the most enjoyable aspects of programming is seeing the result of our work, having the capability to test our code at any given point is beneficial. And if for some reason it doesn’t work, we can likely figure out where it went wrong faster if we’re testing in a frequent and consistent manner.

Unit testing can also lead to an overall better understanding of how our code works. As TGM indicates, unit testing helps us figure out how our code will behave under a large range of circumstances. By running frequent tests, we can gather a better understanding of exactly what our code is doing, regardless if the tests pass or fail.

TGM’s blog was an interesting read for me, especially in regard to his insights of how unit testing can be rewarding. I’ve always known that testing code was important for functionality reasons, and now I feel that frequent testing can help make me a better programmer in general. This is due to what TGM indicated about how we can learn more about our code through its behavior during pass/fail tests.

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

https://sandit27.wordpress.com/2008/03/24/what-are-anti-patterns/
This week’s post focuses on Anti-patterns. Patterns defines a common solution to a problem that occurs through different settings. It is a general solution that can be specialized for a given context. In software design, it helps to capture the best practices that can be reused and applied in the development of different types of software.
In CS, anti-patterns are repetitive practices that appears beneficial, but will most likely result in bad consequences that will outweigh the advantages. It is called anti-pattern because the use will produce negative implementations. Two key elements are used to distinguish an anti-pattern:
A repetitive pattern that appears beneficial but ultimately produces negative results that outweighs its advantages.
A refactored solution that has been documented, proven in practice, and repeatable.
Anti-patterns should be diagnosed early. The following are some of the classic Anti-Patterns:
Organizational anti-patterns:
The “I told you so” the ignored warning from an expert is justified.
Mushroom management is when employees are kept uninformed or misinformed.
Project management anti-patterns:
The smoke and mirrors shows how unimplemented functions will appear.
Finally, software bloat is for allowing successive versions of a system to demand more resources.
I chose this topic because I thought a blog post on anti-pattern of function as child component was interesting. The post can be found following this link, http://americanexpress.io/faccs-are-an-antipattern/. The article argued that Function as child component, FACC is an anti-pattern. FACC is a pattern that allows users to pass a render function to a component as child prop. It allows users to pass as children to a component/function.
FACC was argued to be an anti-pattern. The example was a summation function of 2 numbers and returns the result. Clean code practices recommends descriptive names for properties, variables, and functions. So, in this case the best practice is to name it as add or sum, but not children. The function passes render callback functions through a prop named children. The main issue here is that the FACC function uses the prop children to pass in render callbacks. This pattern goes against what is considered best practice, so it is an anti-pattern.
I chose this article because it introduces an anti-pattern in a reactjs function and reactjs articles are always an interesting read. It argues that naming props as children in the FACC function was not the best practice. It goes against what is considered to be the “Clean Code” standards. I thought that this article was worth a blog post because it was an interesting read.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Equivalence Class Testing
This week we turn to equivalence class testing. Equivalence class testing is a black box software testing technique that divides function variable ranges into classes/subsets that are disjoint. It is beneficial for two cases:
When exhaustive testing is required.
When there is a strong need to avoid redundancy.
Equivalence class testing selects test cases one element from each equivalence class. This helps to reduce redundancy.
There are 4 types of equivalence class testing:
Weak normal equivalence class testing: The term weak refers to single fault assumption. This is accomplished by using one variable from each equivalence class in the test case.
Strong normal equivalence class testing: The term strong refers to multiple fault assumption. This method uses test cases from each element of the cartesian product of the equivalence classes. The cartesian product guarantees the notion of completeness in that all of the equivalent classes are covered and there is one of each possible combination of inputs.
Weak robust equivalence class testing: This term combines weak with robust, meaning single fault assumption with invalid values.
Strong robust equivalence class testing: This term combines strong with robust, meaning multiple fault assumption with invalid values. The test cases are the cartesian product of all the equivalence classes.
This article talks about redundancy in equivalence class testing. It introduces the following problem: Suppose a there is a UI for creating user accounts. The Username is between 1 and 25 characters, spaces are not allowed. The gender can be Male or Female. It would be impossible to test all combinations of inputs instead we turn to equivalence class testing.

Breaking the conditions down EC reduces the test cases into 5 equivalence classes.

Field
Description
3. User Name
Empty
4. User Name
Length > 25 (no spaces)
5. User Name
Length > 25 (containing a space)
6. User Name
Length >1 and = with >.

I chose this post for its simplicity and example of the UI for creating user accounts. The example helps to connect the concept of EC to test cases that can be validated. So, it helps to break down the problem into different ECs and its product into different test cases. It also demonstrates the advantages of EC in helping to reduce redundancy and test time. I chose this post because it gives a good example of EC testing.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

So, I was reading a blog called Awesome Testing the other day, (really clever name, I know, it’s what caught my attention) and I saw a whole section of pages titled “TestOps”. Intrigued, I ventured further by reading the posts, which led me to the initial blog post that coined the term, by Seth Elliot. The short and sweet of it is that originally testing can be represented by this diagram:

The tests are created, they are run on the system, the results are obtained, the results are checked against the ‘oracle’, and an assessment is completed. However, the interesting thing is the current trend in software products. The most popular products now a days are not simple programs, but are actually services. Facebook, Amazon, Twitter, etc. With this new change, testing becomes a bit more different. Big Data concepts are used, new features are tested with exposure control and monitors. This becomes the new model:

The testing system becomes a whole architecture testers are serviced with maintaining and using. This whole post was incredibly interesting to me. As someone new to Software Testing, my experience up until now has been discrete test cases and suites. With TestOps however, testing becomes a whole new beast. Using Big Data techniques to test how well a service is doing, not just if it runs correctly was a definite surprise. As someone who is currently dipping their toes into Big Data as I take a Software Quality Assurance course, I didn’t expect the areas to meet like this.

The final paragraphs of the post describing how this development is also blurring the lines between tester and developer is exciting. There was the worry in the back of my head, that software testing and development were two divided areas. That one had to choose one or the other. But knowing how much they will intermingle in the present and future helps alleviate this to a great extent.

It also makes a large amount of sense. As the software being tested becomes much more dynamic, testing must as well. Not just testing if software is working, but working well is quite the interesting distinction that requires more complicated solutions. These tests will require a process similar to software development to create. Choosing the right kind of Architecture, using tools similar to software process management tools to cut down on the time QA requires to make new tests or change existing ones, and the continuous updates and integration.

The incredibly interesting blog post can be found here: https://dojo.ministryoftesting.com/lessons/the-future-of-software-testing-part-two

The original blog post that sent me to it: http://www.awesome-testing.com/2016/07/testops-missing-piece-of-puzzle.html

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

Gregory Falco: Protecting Urban Infrastructure Against Cyberterrorism

         This article from MIT shows the story of Gregory Falco who is a PhD student that works with urban planning and computer science. The article talks about the IoT (Internet of Things) where everyday objects are embedded with the basic functions of communications to other devices through the internet. Falco works with getting this project off the ground and around the world to other countries so that everyone can have the positive effects of this technology. He says it will help solve their problems with sustainability issues and social problems. However, there were concerns with security of this new system as it is possible for new technology to be susceptible to hacking. Falco continues to explain in the article that IoT devices usually have little to no real security software as they only have small amounts of memory and low-power processors. This can become a “gate” for hackers to exploit bigger systems as they may all be linked on one network. Falco is working on the industrial controls and embedded systems within the IoT such as automatic switches. He goes into detail of all the dangers this hack could create for a variety of people. IoT devices can control anything from subway switches to insulin pumps which puts a large number of people at risk.

            I chose this specific article because it was really interesting that as technology gets to be smaller, we are running into roadblocks like this. This is a very important roadblock because it shows that we need to develop technology to meet these needs faster or many people could lose lives. I found it was interesting how hackers can exploit the smallest flaw in a system to extract dangerous information. I think that the resource was quite interesting and made me more aware to the dangers of having little no security on devices. I feel that technology needs to have some sort of real security behind it as we are constantly relying on for our life functions such as water grids and electric grids. I learned quite a bit on this material from how much technology is taking over our lives to how insecure and manipulated it can get. This helped show me the side of hacking where even small flaws within a system can be used to hack into a much bigger system. It can be important to learn this sort of material because it really shows you to be careful when designing programs and working with networks to make sure that you know what data to keep private vs public. If you give the user access to public data, they can use it to break the system and cause a lot of damage to the program.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

We’ve been discussing this in class for the past couple of weeks so I thought this would be a good topic to reflect upon. Unified Modeling Language, or UML, can be described as the graphical representation of a program’s structure. This is useful for documenting relationships of, for instance, objects and classes in a given structure. Furthermore, UML diagrams can provide general descriptions of the intended behavior and purpose of these classes and objects.

I felt it would be useful to learn more about how to make the “ideal” UML diagram, and Bellekens has a good blog in regards to this topic.

GeertBellekens: UML Best Practice: 5 Rules for Better UML Diagrams

The blog is a good read on the subject because it emphasizes the importance of consistency as well as simplicity when designing UML diagrams. Five general “rules” were discussed in Bellekens’ blog. I will summarize these below while simultaneously providing my personal takeaways from each of them.

Less is more.

When designing UML diagrams, it is important to provide the user with information that is clean, easy to follow, and straight to the point. If a diagram has too much going on, it is bound to confuse and overwhelm the user with excessive information.

No crossings.

Bellekens explains that when designing a UML diagram, there is no need for lines to cross when pointing to the various objects within the structure. Instead, enough space should be allocated to prevent this line crossing from happening. If one is unable to find the space to prevent crossing, this is often a good indication that there’s too much going on in the diagram in the first place.

Orthogonality.

While it is possible to make diagonal lines when pointing from one object to another, I feel it does not nearly look as clean as straight lines and right angles. Other than a few minor exceptions, such as pointing to notes, Bellekens suggests to avoid making diagonal lines in UML diagram at all costs.

Parents Up.

In regards to inheritance and other hierarchies, “parents/superclasses” should always be above their “child/subclass” counterparts. This makes sense to me because whenever I think of something such as a UML diagram, I think of a family tree; oldest on top, youngest on bottom.

Tidy Up.

A great closing argument to Bellekens’ five rules of UML diagrams. Maintaining the validity of UML diagrams and keeping them up to date is just as important as designing a solid graphical representation of our programs in the first place. A UML diagram that is outdated and cluttered with unnecessary information can be frustrating to say the least. Furthermore, keeping objects aligned in an orderly way makes UML diagrams easier to follow and pleasing to the eye.

I look forward to learning more about Unified Modeling Language Design in the upcoming weeks – I am sure I will use Bellekens’ tips on creating solid UML diagrams in the near future!

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