https://www.artofsoftwaredevelopment.com/art-or-engineering/is-it-art-or-engineering

This blog is on the topic of art of software development. The author believes the software development is like art. He also explains why it matters. Teaching someone about software development with the concepts and technique of programming is similar to teaching someone about art. Both difficult and challenging. The final product depends on the student and mentor. The author compares telling a programer how to write a program to someone telling Van Gough how paint his masterpieces. Both end with negative results. Similar the final product of an artwork depends on the student and mentor’s insight.  The author briefly gives us the definition from engineering and art both which come from Wikipedia. Engineering is “the application of scientific, economic, social and practical knowledge in order o build, invent, maintain, research, and improve structure, machines, devices systems, material and process.” Art is “a diverse range of human activities and the products of those actives usually involving imagination or technical skill.” He then states software development comes from the imagination and technology of humans. Software developers can choose the founding blocks for their programs to make it run. The author concludes that yes software development is in a way a form of art and engineering. Like artists, developers need the freedom  to choose how to code and write the program. They can write a program for a client within a certain parameter, but still need the freedom to do it how they want to. Give the programmer too much of a restriction on the program and they won’t have enough freedom or space to create the program and make it run properly. The author does not fully explain on why it matter, he gives his opinion on what he thinks then leaves the question open ended for reader to decide for themselves.

Again, I liked this blog. I agree with the author of software development being a mix of both art and engineering. You need a creative mind to create a program but you also the technical skills to know how to run the program. Again this gives me an idea of how developers work and what they can do.  I have always seen programming as a type of art. My parents have told me I’m artistic with technology and learning how to write programs. I have always been able to figure out how technology works, and figure out how to fix them if theres is a problem.

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

After learning more about JUnit testing I found this blog that really emphasized what we can do to keep our test code just as clean as our program code. You can find the blog here: https://blog.codecentric.de/en/2016/01/writing-better-tests-junit/

The beginning of the blog goes through the value of testing code and the importance of living documentation to help people that join your team half-way through a project. You should read that part if you want to, but my main focus of this blog is the basis of keeping the testing code clean and understandable so that people can understand what is actually going on.

Behaviors!

One way to write better test cases in JUnit is to test behaviors and not implementation. Writing test cases based on implementations will lead to fragile tests that break easily.  The blog gives the definition of behavior as “the range of actions and mannerisms made by individuals, organisms, systems, or artificial entities in conjunction with themselves or their environment”.  I could not find a better way to word it then what the blog had here:  “”Range of actions and mannerisms” – this explicitly limits our view to what is observable from the outside. If we refrain from disclosing internals, and phrase our tests accordingly, they should become much more flexible, and enable us to refactor, replace and/or rewrite large parts of the production code without additional effort” Essentially, we shouldn’t be testing specific variables but rather the universal behavior of the methods on their environments.

Context Grouping

Another helpful technique to make your tests look as clean and understandable as possible is to group the tests by context. This means that you write your tests in a type of hierarchy.  In the blog they use the form “Given-When-Then”  meaning you should write your tests in a hierarchy like this:

This creates a tree of tests in the JUnit Runner window like this:

This is a huge tip to keeping  testing code clean and easy to read, which I had not known about previously.

Single Assertion Rule

This is another tip that will certainly help me keep my tests cleaner because I had not heard of this before. The single assertion rule is just a way of saying that you should only have a one Assert.assertEquals(). This is because it makes looking for why the test failed that much easier, only looking at one value instead of two or more assert values.

Meaningful Names

This one has always been important. Make sure to use descriptive names rather than generic variable names like “x”, “data”, “input”. For example you could use “inputFromEveryDataFile” to improve on the name “input” if you were actually reading all the data from every file.

There are many more…

There are many tips out there to writing more clean and readable test code for JUnit. I couldn’t possibly document every single one! There is no such thing as code that is “too easy” to read so keep cleaning!

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Coding Blocks – Design Pattern- Episode 2

I think this was one of the podcast episodes I was really excited to see. The topics was design patter so I figured I would hear things and concepts I was familiar with and also serve as a measure for me to test what I knew and how in-depth I could follow the episode. Right off the bat, they begin to talk about the absence of design patterns in their curriculum when they were in school. This made a light bulb go off. Meaning I am technically ahead of that era in terms of the tools I am being provided in school to better succeed in the real software construction and development world. Joe Zack also mentions that he knew the big O notation for the entire basic sorting algorithm, which is something I am also familiar with. I am currently an expert at the shell-sorting algorithm. With all the things they were talking about I was able to face reality that I am not really too far away from being a developer on a software development team. Also it demonstrated how much the field of software engineering has changed. It’s crazy for someone to graduate from computer science and not know what design patterns are in today’s world. All projects and programs   today utilize design patterns to create a hierarchy of classes comprising of parent, children, abstract and class interfaces. This helps organize and makes thing more legible for the next programmer that is hired to “maintain” the program. To become a great programmer, one need to develop great design and organizing skills that can be translated into project design patterns. Again Design pattern can actually be divided into three (3) categories.

1. Creational Patterns. (Factories, Builders, Prototype and Singletons)
2. Structural Patterns. (Adapter, Bridges, Flyweight, Proxy, etc.)
3. Behavioral Patterns (Observers, strategy, Chain of responsibilities, etc.)

This I did not know!

Creational Patterns: They help encapsulate the logic of creating classes in a more separate class where classes are created and represented outside the logic that utilizes the creational pattern.

As the discussion got deeper, I noticed that most of these guys recording the podcast have done tons and tons of projects that utilize some of the concepts they are talking about. Right of the bat, I got the initiative to start a project and try to use and implement as many new concepts as I can. Because after all, the best thing you can do for yourself as an upcoming developing in school is to start many projects on your own and try implementing new things you learn and read in school because in the worst case, you familiarize yourself more with topic and concepts that get taught in class.

Link

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/episode-11-design-patterns-part-1-you-create-me

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

Unfortunately, or fortunately, this post is not about automatic testing. According to the author of this interesting post, James Bach, automatic testing is as feasible as automatic programming. That is, not very feasible. Yet, at least.

In a very nice story, James writes a program while his non-programmer and non-tester sister, Erica, stays by his side. He walks through his logic while writing and his sister points out issues while he does so. Despite not having any computer science background, the mere presence of an interested companion leads to better, less issue-ridden programs. This made me remember something from a long time ago, when I was told about the somewhat infamous rubber duck test.

For those that don’t know, the rubber duck test is when a programmer, aloud, describes how his or her program works…to a rubber duck. It sounds ridiculous, but the mere act of trying to explain ones own work in an understandable way can lead to discovering issues that might otherwise be unnoticed. A design fault that seems obvious in hindsight but was looked over as the programmer becomes tunnel focused while in the midst of programming.

This very neatly explains the need for a tester, or at the very least something to get a developer to think in a different way about their work. Along with this, it also demonstrates the natural problem solving nature of a programmer that seems inherent. The need to resolve the conflict of a companion not understanding you is something familiar to me. My middle-school aged brother sometimes asks me about stuff I’m doing, which very many times turns out to be classwork. I have surprised myself with how much I wanted to clear up any looks of confusion I got when attempting to explain a mathematics problem or a program I was having issues with.

This natural motivation of wanting to be understood can lead to much deeper introspection, especially when the other party is not very familiar with the concepts being explained. It often leads to a long series of “Why?” questions. Something James himself calls ‘drilling down’, continuously being asked for more details. Trying to frame key concepts one believes they understand can lead to realizing flaws in ones understanding or incompleteness.

I really enjoyed this article, the story was nice and familiar. It made me realize how basic a necessity a tester, or at least just someone other than the programmer or something else other than the programmer is to creating a program. Or while not a necessity, such an incredible boon to the entire process, that it should be.

Original post: http://www.satisfice.com/blog/archives/852

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.

This blog that I chose to write about this week was a blog post titled “Design Patterns in Real Life” where the author Karthik Kumar creates his own examples of design patterns modeled after real-world situations to help him and the reader understand design patterns better.

http://karthikkumar.me/design-patterns

I chose this blog because I think it is important for those learning new programming concepts to get examples that relate to the real world because it helps them understand these concepts a lot faster.

Kumar begins his blog by explaining how after reading a popular book “Design Patterns”, he noticed that many of the examples used in the book were hard to relate to and the “Known Uses” of each chapter were outdated. To help understand the design patterns better, he created his own examples for each design pattern. In this blog, he explains patterns with his tangible, real-life examples.

Kumar starts off by explaining “Creational Patterns” which deals with how objects are created. They control how objects are built and can have a huge impact on improving the design of the system, it can also allow a system to be independent of how its objects are created.

He then goes into detail of a creational pattern called the Builder Pattern. This pattern separates how an object is constructed from its actual representation. It allows us to use the same general construction process to create different representations.

The real-world example Kumar uses for the Builder Pattern is the car manufacturing industry. In this example, he explains how when building a certain car according to specification, the manufacturer chooses several options about the car. This could include the color, engine, and any additional features. In this example, the client interacts directly with the builder to manufacture cars. The advantage of using the builder pattern is that we can construct cars with different characteristics using the same builder, and by specifying different parameters to the builder.

Kumar then explains Structural Patterns with deal with how classes and objects are built and composed as part of a larger system. He continues with the structural pattern the “Facade Pattern” which provides a single unified interface that encompasses several interfaces in a subsystem. It acts as a funnel to expose a single interface to many clients, and hides the actual subsystem that’s responsible for doing the work requested.

The example Kumar uses for the Facade pattern is Amazon’s 1-click ordering system. When ordering items, a customer is presented with a simple interface to purchase an item, but there are several complex processes running to enable an item to be purchased, and the user doesn’t see that.

Kumar takes these design patterns that may be hard for us to understand and uses everyday real-world examples to make understanding each design pattern easier, which I really like. I hadn’t looked at these design patterns in depth before and this blog helped me understand them quickly thanks to the examples provided.

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

Source: https://blog.codinghorror.com/if-it-isnt-documented-it-doesnt-exist/

“If It Isn’t Documented, It Doesn’t Exist” are probably some words to live by, written by Jeff Atwood. Jeff expresses his thoughts on proper documentation based on his personal experience while working on open source projects. This can be summarized into a single sentence “Good Documentation is hard to find” as stated in the blog. However, he agrees on a couple of key points made by James Bennett who wrote the blog post Choosing a JavaScript Library. These can be summarized to having a proper overview of each section of your project/design, having proper examples of usage when needed, documentation on everything, and your regular comments throughout the code itself. Although it was specifically written for his javascript explanation, I attempted to apply it to regular java coding as well. Ultimately leading up to another great statement “most treat documentation like an afterthought” made by Mr. Bennett.

Truthfully, upon finishing and reviewing my own code for Assignment 1 in my CS-343 class, I realized that documentation or comments within the code is non-existent. Leading up to relearning the importance of proper documentation, as once taught in my CS-140 class. Currently, I can see that it is not a requirement and has not been a big factor in assignments even in other previous CS courses I have taken between CS-140 and CS-343. However, it’s important to remember that a properly documented project can be easily benefit yourself and others in many ways. For example, it can be used to assist in explanations or allow others to understand what is done at a certain point. Also, it can be used to help yourself pick up where you left off after reading up on what you have written. Simply stated as “…if you’re the only one who understands it, it doesn’t do any good” by Nicholas Zakas.

Practicing proper documentation techniques early on will help develop proper skills for determining how much is necessary to document. Too much unnecessary documentation will hurt more than documenting only what is needed, which is a problem I had when I actually applied documentation within projects. This also includes being able to understand when and where to use comments, javadocs, etc. throughout a project. Currently, I do treat documentation like an afterthought, to the point that it isn’t applied. In the future, I hope to apply this skill and use it to my advantage, not only for myself but for others as well.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This week i chose a blog on unit testing which can be found here: 7-tips-writing-unit-tests-java. I chose this article because we are starting to look at J unit testing in the class and this article seems to give a good overview of some of the fundamentals on unit testing.  This article is designed to help you write better unit tests, and it does this by recommending 7 tips.

The first tip in the article is to use a framework for unit testing. The two frameworks that the article talks about are the two most popular, which are JUnit and TestNG. These frameworks make it much easier to set up and run tests, and makes tests easier to work with by allowing you to group tests, set parameters and many more options. These frameworks also support automated test execution by integrating with build tools like Maven and Gradle. They close this tip out by talking about another add on to Junit or TestNG which is called EasyMock which allows you to create mock objects to facilitate testing.

The second tip is Test Driven development, this is a process in which tests are written based on the requirements before any coding begins. The test will initially fail, the minimum amount of code is written to pass the test and the code is refactored until it is finally optimized. TDD leads to simple modular code that is easy to maintain, and speeds up the development time.  TDD however is not suited for very complicated design or applications that work with databases or GUI’s. The third tip is Measuring code coverage, generally the higher the percent of code that is covered the less likely you are to miss bugs. The article mentions some tools like Clover, Corbetura, JaCoCo, or Sonar which point out areas of code that are untested. This can help you develop tests to cover these areas. High code coverage does not however insure that the tests are perfectly working.

The fourth tip in the article is to Externalize the test data wherever possible. This is done so that test cases can be run for different date sets without having to change the source code. The article also gives code examples of how you would do this in both Junit and TestNG. The fifth tip is to use assertions instead of print statements. Assertions automatically indicate test results, while print statements can make code very cluttered and require manual intervention by the developer to verify the output printed. The article compares two test cases, one with a print statement and one with an assertEquals, the print statement test case will always pass because the result needs to be verified. The assert version will fail if the method returns a wrong result and does not require developer intervention.

The sixth tip is Build tests that have deterministic results. This tip talks about how not all methods have a deterministic result. The article gives an example of code for a very complex function in which a method calculates the time required for executing the complex function. In this case it would not make sense to test this because the output is variable. The seventh and final tip is to Test negative scenarios and borderline cases, in addition to positive scenarios. This includes testing both valid and invalid inputs , and inputs that are borderline as well as the extreme values of the inputs. This is similar to the testing that we have done in class such as Robust worst – case testing.

I chose this article because we are starting to look at unit testing and specifically JUnit testing and i thought it would be interesting to look at some of the basics of unit testing to familiarize myself with it. Some of the parts that stood out to me are the part on Test driven development and code coverage. I like the Test driven development because it seems like it would fit well into Object oriented design and allow for some sleek coding. As for the code coverage area i like how it included multiple plugins that allow you to test code coverage, these are programs that i have never used before and which seem like they would be of great help in both testing coding coverage and figuring out which sections of code you need to test next.  The last couple tips seem to be very similar to the type of testing we have been doing in class which gave some insight on how the types of testing we have been using can be used in Unit testing. The last thing that i like about the article was the code examples of tests that were included for both Junit and TestNG, which gave some insight on how certain tests could be run and also one some of the differences between Junit and TestNG.

In conclusion i enjoyed the article even though it was quite simple at times. It gave a good insight on Unit testing and the different tools that can be used to write better tests and to make your life as a tester much easier and enjoyable. My one complain is that the article does not go into very much detail in some of the sections. Specifically the sections on deterministic results and the section on assertions, i felt that both of these sections could of benefited from including greater detail. Both of these sections were not very long and only have one example, additional examples and greater detail would help get the ideas across much clearer.

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

The article referenced in this blog post can be found here.

This past week I found an article which put forward an unconventional idea: unit testing smells. I picked this article because applying the concept of code smells to test code was intriguing to me. The idea is that certain things that can happen in the course of writing and running your test code can inform you that something is not quite right with your production code. They aren’t bugs or test failures, but, like all code smells, indicators of poor design which could lead to difficulties down the line.

Firstly, the author suggests that having a very difficult time writing tests could signify that you haven’t written testable code. He explains that most of the time, it’s an indicator of high coupling. This can be a problem with novice testers especially, as they’ll often assume the problem is with them rather than the code they’re attempting to write tests for.

If you’re writing tests well enough but doing elaborately difficult things to get at the code you’re trying to test, it’s another testing smell. The author writes that this is likely the result of writing an iceberg class, which was a new term for me. Essentially, too much is encapsulated in one class, which leads to the necessity of mechanisms like reflection schemes to get to internal methods you’re trying to test. Instead, these methods should probably be public in a separate class.

Tests taking a long time to run is a smell. It could mean that you’re doing something other than unit testing, like accessing a database or writing a file, or you could have found an inefficient part of the production code that needs to be optimized.

A particularly insidious test smell is intermittent test failure. This test passes over and over again, but every once in a while, it will fail when given the exact same input as always. This tells you nothing definitive about what’s going on, which is a real problem when you’re performing tests specifically to get a definitive answer about whether your code is working as intended. If you generate a random number somewhere in the production code, it could be that the test is failing for some specific number. It could be a problem with the test you wrote. It could be that you don’t actually understand the behavior of the production code. This kind of smell is a hassle to address, but it’s absolutely crucial to figure out.

Having read this, I won’t just pay attention to whether my tests yield the expected result, but will look out for these signs of design flaws in the code being tested.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

This week, I decided to tackle the idea of frameworks. I personally have messed with Bootstrap, Spring, and Node/Express. Even with some experience tinkering around in these frameworks, I still did not quite comprehend why they are such a required skill to develop in their respective languages.  I chose this article because everywhere you look in the software development world, everything is about the latest framework. This can be from blog posts, tech articles, and most importantly, job postings. Everyone is expected to know a major framework for the language that is listed as a required skill. This article I found on InfoWorld, tackles what makes frameworks so powerful and why they are the foundation of the future of software development.

Probably the biggest point that this article is trying to make is that syntax does not really matter anymore. One of the secondary points to back this is up is the idea that architecture should be the focus instead of the minute details of the syntax of a language. The focus should be on how to utilize existing libraries/frameworks by reading the documentation and figuring out the little details as you go. Personally, when I first started writing code, I focused excessively on the syntax of Java instead of understanding data structures themselves. This is a good example because most of the data structures we use in practice are part of the Collections framework within Java. A strong understanding of this framework has helped me write better code more efficiently.

Another secondary point that the article makes to back up the idea that syntax is dying is the growing area of visual languages. This was completely new to me, as I would not really consider visual languages to be part of the software development process. It is hard to ignore the growth in products like SquareSpace, Wix, and tools like AndroidBuilder. While Wix and SquareSpace are not exactly what the article is referring to, I feel that it is important to consider these tools regarding visual languages. These tools alleviate the need for developers for small business owners who only need simple websites/web applications. I’m not too familiar with AndroidBuilder, but from the article, I can gather that this is more of a tool for a developer to manipulate. I do agree with the article that while visual languages will continue to grow, they will never replace the traditional means of creating applications. This does however, mean that they diminish some of the need for learning nitty-gritty syntax.

These are just a couple of the seven reasons that the author feels that frameworks are becoming the new programming languages. I hope to use the core ideas of this article when tackling frameworks, including Angular.js which we will be working with shortly. Considering my minimal experience writing Javascript applications, this will be necessary if I want to be successful for my final project. Hopefully I can translate my new knowledge into productivity.

Here is the original article: https://www.infoworld.com/article/2902242/application-development/7-reasons-why-frameworks-are-the-new-programming-languages.html

From the blog CS@Worcester – Learning Software Development by sburke4747 and used with permission of the author. All other rights reserved by the author.

For this post I chose an article called “Black box, grey box, white box testing: what differences?” I chose this article because grey box is something I haven’t seen explained and I thought it would be a good idea to get the concepts of all three types explained to use as a reference down the road.

The first type explained is black box testing. This is described as testing having a user profile. You are testing for functionality and that a system does what it is supposed to do but not how to do it. In other words, the internals or code of a system is irrelevant to your tests. The priority is testing user paths and that all the system behaves correctly on each path. Some benefits of black box testing are that the tests are usually simple to create which also makes them quicker to create. Drawbacks include missing vulnerabilities in underlying code as well as redundancy if there is already other testing being done.

The next type of testing is white box. This would be testing having a developer profile. You have access to a systems internal processes and code and it’s important to understand that code. Things white box testing is aimed at checking is data flow, handling of errors/exceptions, and resource dependencies. Advantages of white box testing include optimizing a system and complete or near to complete code coverage. Disadvantages include complexity, takes a lot of time, and it can get expensive.

The last type of testing is grey box testing. As the name suggests it is a mixture of both black and white box testing. The tester will be checking for functionality with some knowledge of the internal system however still does not have access to source code. One advantage of grey box testing is impartiality, basically a line still exists between tester and developer role. Another advantage is more intelligent testing. By knowing the some of underlying system you can target your testing to better cover the functionality. The main disadvantage that still exists is the lack of source code access. Without this you cannot provide complete coverage of testing.

After reading the article it seems going with only one of these types of testing would never really be enough. I would argue that white box testing seems to be the most important. Being able to actually test a system internally and cover your code is extremely important. Without access to the code, a functionality that fails testing is almost useless as it could be many things that caused it to fail. I feel like the description of grey box testing is a little vague. While the tester may not have access to the source code, I’m unsure as to how much they actually know. In conclusion this was a good refresher on black and white box testing as well as a good intro to grey box testing.

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