Apprenticeship Patterns Blog Post #3

After completing my apprenticeship introduction blog post and two different patter reviews, I am excited to keep reviewing more. For the next pattern from the textbook that I have chosen to review, I chose the “concrete skills” pattern. The book describes a situation in which you are trying to work with a group or at a job in which you do not have a very strong background in yet. This is ofter one of the most inconvenient thing when looking for starter jobs. Most jobs want individuals who have a good background so they know you will be a good fit for the job. The book also supplies us with a great solution to this problem however. Basically, it states that you will have a better chance getting the job if you can prove that what you lack in background work, you make up for in your ability to learn quickly and work hard to learn new things on your free time as well. The more jobs and projects you can accomplish/work on, the better your portfolio and background becomes overtime. Eventually you will find it easier and easier to get where you want to get, and it all starts with your first several projects/jobs. This specific apprenticeship pattern resonated with me primarily because I personally do not have a great background yet and am trying to create a good one. The advice from this section was super powerful, and to be honest, this might be one of the most important concepts discussed in the entire textbook!

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

Sweep The Floor

This post will be about the “Sweep The Floor” apprenticeship pattern from the book, Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This pattern is about finding your place on your team, contributing to the teams work to earn their trust and respect, and growing as a developer. The pattern suggests taking on the undesirable peripheral tasks when joining a new team/project. This will help you learn more about the project, development as a whole, and will keep you away from the core of the project. These tasks are often overlooked in education so this can help you fill in the gaps of education while working on something low risk. This does not mean lack in quality though. keep good quality, as bad quality on these portions of the project can become troublesome later on.

There are some problems with this pattern mentioned by the authors that I agree with. One is that you may become the guy who they use to do such dirty work, lacking in opportunity to work on more challenging tasks. Another problem is that you may become intimidated by anything that isn’t the easy yet boring work. Although you learn from this work, there becomes a point where you start to plateau from lack of challenge. The authors solution for these problems are to advocate for yourself and look for every opportunity where you can show them you are capable of contributing to higher tier work. Showing them enthusiasm and skill should make them realize that you are ready and capable to move on to more skillful tasks.

I found this useful because everyone has this starting point where they’re at their first job in a profession and need to gain the trust of their team members. Showing them that you are there to contribute can go a long way and nothing shows that better than when you do the tasks that no one wants to do. Although I already had an idea of this, the book really gave me a solid idea of what to expect to do at my first job as a developer and how to get my team to welcome me.

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

differences and benefits between JUnit 4 to JUnit 5:

https://www.baeldung.com/junit-5-migration

According to this blog what I study for the Junit 4 and Junit5:

JUnit 5 is a powerful and flexible update to the JUnit framework, providing various improvements and new capabilities to organize and describe test cases and to help understand test results. Upgrade to JUnit 5 is quick and easy: Just update your project dependencies and start using the new functionality.

JUnit 4 bundles everything into a single JAR file.

JUnit 5 consists of three sub-projects, namely JUnit Platform, JUnit Jupiter, and JUnit Vintage.

1. JUnit platform

It defines TestEngine’s API for developing new testing frameworks that run on the platform.

2.JUnit Jupiter

It has all the new JUnit annotations and TestEngine implementations to run tests written with those annotations.

3.JUnit Vintage

Support for running tests written by JUnit 3 and JUnit 4 on the JUnit 5 platform.

But here are four strong reasons to start writing new test cases with JUnit 5:

JUnit 5 takes advantage of features from Java 8 or later, such as lambda functions, to make tests more powerful and easier to maintain.

JUnit 5 adds some very useful new capabilities for describing, organizing, and executing tests. For example, tests get better display names and can be organized hierarchically.

JUnit 5 is organized into multiple libraries, so import only the functionality you need into your project. With build systems like Maven and Gradle, it’s easy to include the right libraries.

JUnit 5 can use multiple extensions at the same time, something that JUnit 4 cannot do (you can only use one runner at a time). This means that you can easily combine Spring extensions with other extensions, such as your own custom extensions.

The JUnit 5 tests look pretty much the same as the JUnit 4 tests, but there are a few differences you should be aware of.

The import. JUnit 5 uses the new org.junit.jupiter package. . For example, org. Junit. Junit Test into org. Junit. Jupiter. API. Test.

Annotation. The @Test annotation no longer has arguments; each argument is moved to a function.

Assertions. JUnit Assertions 5 now in org. JUnit. Jupiter. API. Assertions. Most common assertions, such as assertEquals() and assertNotNull(), look the same as before, but with a few differences.

The hypothesis. Assumption has been moved to org. Junit. Jupiter. API. Assumptions.

In summary, JUnit 5’s tests are more powerful and easier to maintain. In addition, JUnit 5 offers many useful new features. Only the features you use will be imported, you can use multiple extensions, and you can even create your own custom extensions. Together with the new features, these changes provide a powerful and flexible update to the JUnit framework.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Unit Testing vs. Integration Testing

The basic idea of unit testing is that you are testing individual units of source code that you have written to see if there are any bugs. Usually the code is deterministic so there are set outputs. The idea of integration testing is to test how a group of modules in your application are working together including how external dependencies are working with the code. This usually involves testing something that is non-deterministic in the application.

Integration testing usually comes after unit testing and is the more expensive to maintain. While the developers will run the unit tests, integration tests are usually required to be ran by a test team. This is partly due to the difficulty in finding errors in integration tests as well as the time it takes.

Integration testing is black box testing which means you are testing the inputs and outputs of the interface. An example of an integration test would be checking the interface to see if you are brought to your profile home page when you enter your username and password. Unit testing is white box testing so you are writing test cases for certain functions to see if they perform correctly. An example of a unit test would be writing a JUnit test case to test the deposit() method and assert that when you make a deposit of $50 to your bank account object (with initial balance of $0) that your balance is now at $50.

The main takeaway is that integration testing tests the interface and how multiple modules work together while unit testing is testing the source code of one function. Unit tests are done in early development while integration tests are done after you have some sort of product complete.

Sources:

https://www.guru99.com/integration-testing.html#3

https://www.guru99.com/unit-test-vs-integration-test.html#:~:text=Unit%20Testing%20test%20each%20part,see%20they%20are%20working%20fine.&text=Unit%20Testing%20is%20executed%20by,performed%20by%20the%20testing%20team.

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

Why QA is essential

The software development life cycle consists of many parts and one of the essential factors included is software quality assurance. QA for software has the role of establishing and maintaining a standard set of requirements for developing code and making sure the product is properly tested before being available to users. Quality assurance is essential because mistakes are inevitable to happen because the people who develop code are humans not machines. There is always something that can happen that escapes the developer’s eye and so there is another stage of the life cycle to catch this mistake. Now there are many reasons why quality assurance plays a huge role and can really help prevent major problems down the road.

By far the most important reason for quality assurance is money which makes sense because the goal of a business is to make money by selling their products. If code is developed but not tested through QA, then it will be released to the users and they will face problems. This will bring many additional problems to the company since their product failed because the right precautions were not taken. It is essential to test for as many unexpected problems that come to mind, and this is why a quality assurance process is needed to clear up these issues. Another big reason for quality assurance is safety for both the user and the company. A person who buys the software is investing in the product knowing that it is safe and their personal data won’t be a threat. If companies don’t ensure their products through quality assurance testing, then they are liable for damages to the user’s life and further safety issues. Adding on to this, once a company is known to not properly test their products and code, then they will be tarnished with a reputation that they are unreliable. First impressions are always important and this also applies to software because the technological world is changing exponentially which leads to a smaller margin of error for software companies to protect their reputation. The essential goal of a business is to create a product they can sell to a client and receive compensation for it. The user wants to spend money so he can be able to use that product for his own good. Therefore, the company has an obligation to make sure they do their best to meet client’s needs and make the best product based on their capabilities. Overall, software quality assurance is an essential process in the development life cycle and can break or make the software.

Additional resources to read up on:

View at Medium.com

https://www.msystechnologies.com/blog/everything-you-would-want-to-know-about-quality-assurance/

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Breakable Toys is a very interesting pattern. It talks about doing and undoing something. You must learn how to break it in order to unbreak it again and really learn its inner parts and how does it work. As the author clearly states, “failure is merely an incentive to try a different approach next time.” Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.

I´ve applied that pattern repeatedly, sometimes breaking it too much that I would take hours to unbreak it, but at the end, taking with me a greater knowledge. This way I learned computer languages. I have a project with requirements, and I must translate it into code. Nothing works with the first try so you have to break your classes over and over again until you get it right. At the end what you gain is experience in that language and knowledge that you can share and use it in the future.

This pattern made me understand that is ok to break and fail. In the apprenticeship pattern book, in the chapter about the breakable toys, the author writes that Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems. I am one of those persons who is afraid to break it because it might damage the whole thing even though it might need that.

Breakable toys is one of those patterns that need to be in your mind all the time. You need to remind yourself that the road to learn something new is not easy and has a lot of failures, but what is important is that you do it with passion. It really doesn’t matter what you decide to do, as long as you experiment and learn.

You can’t do anything well unless you love it, and if you love to hack, you’ll inevitably be working on projects of your own.

—Paul Graham, Hackers & Painters

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Blog Post #1 JUnit 5 Testing

In class, we have been learning about testing with Junit 5 and doing assignments related to it. After watching the video for the advanced part of the assignment,  I decided that I wanted to research further into the topic for my first blog post. So, what is Junit? In a short answer, JUnit is a Java open sources unit testing framework that is used to write and run repeatable automated tests. JUnit 5 Is the updated version of the highly popular testing library that is Junit 4 which I’m sure you all have heard of it. Junit 5 was released in 2017 that adds good use for Java 8 features. In fact, JUnit 5 requires Java 8 JDK or higher to work.

While researching a few of the key differences between the two versions are Junit 5 is composed of 3 sub-projects JUnit Platform, JUnit Jupiter, and JUnit Vintage. The Assertions and Annotations have been changed, and most importantly Junit 5 adds the support of the lambda expression in which we went over in class. One of the blogs I read recommends doing this example,  which I found quite helpful and easy to understand. The code below is just a conversion between Fahrenheit to Celsius and Junit to test it. The author breaks each part down into subsections which made It easier to follow along. I was also, curious about how Junit 5 worked in the Gradle so I followed tutorials to see how the build systems provide supports to the new feature. I highly recommend watching the video that I have provided; it explains everything you need to know about Junit 5 and the architecture behind It.

 

Resources: 

https://www.youtube.com/watch?v=flpmSXVTqBI 

https://www.parasoft.com/junit-tutorial-setting-up-writing-and-running-java-unit-tests/

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Test Driven Development

Link: https://www.thoughtworks.com/insights/blog/test-driven-development-best-thing-has-happened-software-design

            The article linked above talks about test driven development, also referred to as TDD, and how it effects software development. I specifically chose this article since it centers around a topic that we’re supposed to cover in this class. The author explains three key reasons why this type of development is used. The first reason is that test driven development is an iterative cycle comprising of the three steps of failing tests, passing tests, and refactoring code. The “failing tests” phase establishes a baseline to work with, the “passing tests” phase develops that baseline into code that meets minimum requirements, and the “refactoring code” phase further develops that code. The second reason is that TDD forces a developer to question their code on multiple levels. For example, a developer would be pushed to question how a specific component works or what they expect from their code. The last reason is that test driven development allows for faster feedback on software design as poor design is often the reason why testing features fail. The article goes on further to explain how to apply TDD on code that is impossible to test.

            Reading this article, I found myself agreeing with a lot of what the author had to say. What stuck out to me in particular was how TDD forces a developer to question their code. It got me thinking about the habit I developed writing code where I began to write down and plan the general structure of a whatever project I worked on. The way that test driven development pushes someone to understand their code in what component does what reminds me of my habit but on a smaller scale since a developer would usually test a single feature at a time. And this type of development is really a new concept for me since I’ve used that iterative cycle that the author mentioned without even realizing it. The only major difference is that is that I typically didn’t use a test class which is what I’d assume is a given in the context of the article. I usually manually tested my projects which obviously hurt my productivity and deprived me of the benefit of faster feedback in TDD.

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

Getting my feet wet with the JUnit 4 Runner Architecture

Recently as part of a homework assignment, I learned that in JUnit 4, you were only allowed to use one test runner. This aspect of Junit 4 intrigued me so I decided to do a little more research into the architecture of the JUnit 4 Runner Class.

https://www.mscharhag.com/java/understanding-junits-runner-architecture

In this blog by Michael Scharhag, he explains generally what are Runners, how they work and the class hierarchy. Throughout the post, he walks us through the class hierarchy by using a series of tree diagrams and code snippets. He also explains some of the more easily missed details such as what happens when we don’t pass a Runner to the @Runwith annotation. He also talks a little bit about possible pitfalls such extending the wrong class and some neat tricks you can do with the JUnit 4 Runner such as creating custom runners. Overall, I feel like this post was more on the technical side and I used the following video to look at more of the application side.

In this video, it talks more specifically about what each of the classes in the hierarchy do and what annotations to include and when.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

JUnit 5

This week we had our first assignment. This assignment was about practicing writing JUnit 5 test cases. I am familiar with Junit 5 test cases from another computer class in last semester. Because I haven’t used Junit or coding in java for a while it took me a while to remember what I knew and how to code the test cases. JUnit 5 is most widely used testing framework for java applications. For very long time, JUnit has been doing its job perfectly. In between, JDK 8 brought very exciting features in java and most notably lambda expressions. JUnit 5 aims to adapt java 8 style of coding and several other features as well, that’s why java 8 is required to create and execute tests in JUnit 5.

In this homework, we had a BankAccount class and create at least one test class for the Bank Account System using Junit 5. In the base assignment we had to write the test for the methods that were in the BankAccount class and at the same time create a private method. In the intermediate we had to the write tests for which may include Custom Exceptions. In JUnit 5, to test methods which throws exceptions, we should use .assertThrows() method from org.junit.jupiter.api.Assertions class. The assertThrows() method asserts that execution of the supplied executable block or lambda expression which throws an exception of the expectedType.

In the advance I had to watch a podcast from Sam Brannen, Deep Dive into Junit5. The podcast was very interesting. From here I learned the fun fact that Junit5 is called Jupiter, the reason is Jupiter happens to be the fifth planet from the Sun. He explained some advantages and differences that Junit 5 has over 4 like; JUnit 5 has new features for describing, organizing, and executing tests, especially the display names and can be organized hierarchically, Junit 5 can use more than one extension at a time, you can easily combine the spring extensions with other extensions etc.

Overall, I really enjoyed working in this assignment even though I had to refresh my skills in java and writing test cases has always been a challenge for me but that doesn’t mean that I will give up.

https://howtodoinjava.com/junit5/junit-5-vs-junit-4/

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.