Link to blog: https://blog.codecentric.de/en/2016/01/writing-better-tests-junit/

In this blog written by Tobias Goeschel, he makes the arguement that in order to create a readable, maintainable, and useful test suite, we need to change our testing habits by focusing on behavior instead of implementation. Throughout his blog, he outlines some of the aspects that are needed to understand on how to write better tests with J-Unit.

The Value of Test Code

Goeschel states that writing fast, bug-free code is easy, if it’s not too complex, written once, and never touched again. In order to keep the code in high quality and maintainable as possible, you need tests because they allow you to makes changes in the design and architecture, without damaging the behavior. Well written tests will reveal how to access the API, what data is suppose to go in and out, what possible variations of an expected behavior exists, what kind of exceptions might occur, how the individual parts of the system interact with others, examples of a working system configuration, and what the customer expects the software to do.

Test Behavior not Implementation

Goeschel states that we create fragile tests if we set our testing focus on implementation. He then defines behavior as “the range of actions and mannerisms made by individuals, organisms, systems, or artificial entities in conjunction with themselves or their environment.” He specifically highlights that “range of actions and mannerisms” explicitly limits our view to what is observable from the outside. The tests will become more flexible if we refrain from disclosing internals and phrase the tests accordingly.

Group Tests by Context

In order to keep tests organized, we need to make sure that test methods should be grouped closely together. This is important because it helps find each single test, and to understand the behavior of the system much more quickly and easily.

Enforce a Single Assertion Rule

It is important that we try to limit each test method to a single assertion because it makes the code easier to read by assigning meaning to an anonymous block of assert statements.

Choose Meaningful Names

Applying variables and names to method names are important as well. This means that avoiding names like “a”, “test1”, “data” or anything like those names would be best.

Avoid Complex Configuration 

Avoiding complex or bloated configuration promotes fast tests. It applies to extensive use of dependency injection frameworks like Spring. A better way is to declare dependencies explicitly.

Avoid Test Inheritance 

If tests depend on each other, we make it harder and more tedious to change our system. We don’t want our tests to introduce additional dependencies to the code base we create. Inheritance introduces performance problems when working with JUnit.

Overall, Goeschel’s outline of writing better tests with JUnit was very clear and concise as he highlighted the six key actions when performing the JUnit tests. I chose this blog because I was a little unclear about the nature of how JUnit tests are done. This blog made me understand on how effectively test with JUnit. Understanding JUnit may help me in my future career field if video game development because it is another type of test that I can implement when I run and test my gaming software.

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

In this blog post, Justin Albano talks about the basic Strategy pattern and the “fundamental principles that make for solid strategy implementations.” He also goes into the use of Dependency Injection (DI) “to select a strategy implementation” along with a walkthrough of a basic payment system using the Strategy pattern.

The purpose of the Strategy pattern is “to decide the algorithm used in a specific context” by encapsulate algorithms into classes with the same interface, and by using the same interface, we allow the algorithms to be interchangeable based on what is needed. The following is a UML class diagram of the Strategy pattern:

The way the author makes sense of the Strategy pattern is to see the Context class as a desk, “where the Strategy interface represents a slot in the desk that accepts drawers” and each the concrete strategy implementations “can be thought of as actual drawers, where some are completely undivided, and others have various divider configurations; some may be good at storing papers, while others may be better at organizing pens, pencils, and paper clips. Each serves its own purpose and excels in a specific context, but vary only in their internal configuration: The external configuration of each drawer is the same so that it can be accepted by the desk.”

I selected this article because I wanted to learn more about the Strategy patterns, and design patterns as a whole. This post had topics that I didn’t know about like Dependency Injection, using the Introduce Parameter Object refactoring technique. It also goes well into detail an implementation of a payment system showing both the Strategy pattern and Factory pattern. I feel my knowledge of the Strategy pattern has improved after reading this article, and seeing it implemented in a new way helps me understand it more. The author is very detailed and explains the topic clearly. I learned about the importance of selecting the appropriate strategy, whether it’s more appropriate to have a run-time selection (a conditional run-time selection will require logic whose complexity is proportional to the number of possible concrete strategies) or a static selection (Strategy is selected once when the application starts-up and is never reinitialized for the duration of the execution of the application. I plan on using the Strategy pattern when I am developing software, the Strategy pattern has many uses in the world of software development and will continue to be utilized.

The post Java: The Strategy 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.

Over the past few weeks reading about unit testing, I’ve come across a few articles and blogs claiming that unit testing is not the most efficient way to ensure code accuracy and quality. I’ve been under the impression that unit testing is always a good idea, so I wanted to read about Robert Martin aka Uncle Bob’s input regarding this subject. He is a reputable computer programmer and the author of the well-received book “Clean Coder.” The following is a brief summary, along with my personal takeaways, from one of Bob’s blogs entitled First-Class Tests.

Bob is critiquing a TechBeacon blog where the author is condemning unit testing as bad practice. It seems to me that the TechBeacon blog author has claimed to “give up” unit testing for something that he calls “system testing.” But Bob insists that the TechBeacon author is not only running his tests in an inefficient way, but using improper terminology as well.

Bob gives a few definitions of different types of testing, some of which seem to contradict the views of the TechBeacon blog author. First, he explains that unit tests are written to ensure that the code is doing what the programmer intends it to do. Bob then gives his definition of system testing, stating it is not what the TechBeacon author believes it to be. System testing, according to Bob, are “plumbing” tests to ensure the internal workings of the entire integrated system is working as expected. This is in contradiction to the TechBeacon blog who claims he is running “system tests.” Bob claims what is actually being run here is “user-interface to database” functional tests, which are, in actuality, slow unit tests. I agree with Bob’s terminology here; it seems to coincide with what we’ve learned in class regarding unit testing thus far, some of which I’ve discussed in some of my previous blogs.

I believe the main point that Bob is trying to get across is that it seems many people tend to have the wrong idea of what unit testing is. If someone is writing unit tests that rely too heavily on outside resources, for example, it can slow down and hinder the whole purpose of testing software. It can make unit testing seem inefficient, when in actuality is the result of badly written unit tests. He stresses that programmers should not be trying to think of ways to circumvent unit testing. Instead, we should find ways to write unit tests as efficient, clean, and self-sufficent as possible.

I truly enjoyed reading Bob’s blog regarding his opinion on unit testing. I found it both amusing and informative. Bob leaves us with a final thought; we ought to treat our unit tests as “first-class citizens.” I will strive to do this throughout my professional career based on the advice he has given in his blog: I will avoid coupling unit tests with outside resources and make great efforts to always keep my unit test code “clean” and up-to-date.

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

Workshop on Software Architecture for Agile Development

This blog was found from this site. Hayim Makabee, the blogger did a workshop software architect for agile development. At the workshop he did a presentation on Adaptable Design Up Front in an agile project. He explained how much adaptability should be done on a project. The topic was explained with different software architect with different software programs developed over the years. There were also exercises that further explained the definition and the evolution of different design systems. The blogger included pictures and the slideshow from the presentation. I quickly went through the presentation. The first slide after the title slide shows where he worked over the years. Some of the companies he’s worked for includes IBM, Yahoo and many more. Part one of the presentation was on Architecture and agile. In this part he explains the different approaches in the context of agile, the approach of Adaptable Design Up Front, guideline on how to use it in practice and examples of it in the real world. Part two was about manifesto for adaptability. This included lean startup, minimum viable product, manifesto for adaptable software development, SOA principles and micro service practices.

This was a short blog to read. Luckily there was a slideshow to look at. This was again interesting to read. As I went through the slides I noticed he included a design pattern for part one of the presentation. I gave a brief summary of the slideshow and mentions the topics that the blogger talks about. The slideshow goes through it with more detail and explains everything mentioned in the topic. The slideshow also includes many pictures and examples used for the real world. Everything explained in the slideshow had pictures or diagrams making it easy to understand.  The pictures from the workshop show the group working on an activity. The activity ha the audience create a taxi ordering app with design patterns. This activity helped explain the definition and evolution of design of a software. This blog showed me how useful design patterns and software design can be used in the real world. From the picture the group looks like they are learning from the slideshow and enjoyed the worksop overall. I would have found the workshop interesting if was there. His list of job credentials at the beginning of the slideshow sort of gave me an idea of where to  look for a job in the future.

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

Last week I wrote a blog highlighting some of the things you can do to produce cleaner test code. This week I want to dive into one of those tips and explain it a little further so that you can use it in your code as well. This tip refers to the structure of test code to make it easier to read and understand, leading to easier maintenance. The blog I used as a reference is found here:  https://blog.codecentric.de/en/2017/09/given-when-then-in-junit-tests/

I chose this blog because it highlights how to name test cases and how to prepare test objects for your test cases which is important in J-unit testing, especially when you are working on a team and need to leave clean test code so that others understand the purpose of them.

Getting started, JUnit testing can be confusing to look at if you don’t understand Java code in general. However, our goal should be that people who don’t code should still understand what our test is doing. In order to achieve this, we need to start with proper documentation of JUnit test code. Your code should have a header comment that explains exactly what your code is testing for. Like so:

Next you want to split up the test method into a more readable fashion. This is where the Given-When-Then tip shines:

This way you can easily read what is going on with the test. This can still be improved drastically. The test name is testIsPalindrome(), this is not acceptable as it doesn’t actually tell you what the test is doing. Try to summarize the purpose of the test in the test name.

This is a better name for our test method for obvious reasons. But our test case still uses String s for the string we are checking and our variable result is just as vague. The following example is a much more readable test case than our beginning product:

When we use names that actually refer to what is happening, it makes the entire test case easier to read. Again, this is important when writing JUnit test cases because you must be able to work together as a team and leave behind proper documentation which will prevent others from getting confused when reading your code. Notice how you can read the assert line almost as if it was saying “Assert that the string Worcester is not a palindrome.”  If you can write test code that is as black and white as this then you shouldn’t have a problem when working with a team or even referring back to old code.

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