http://www.discoversdk.com/blog/unit-testing-with-junit

          This week, I found a blog post about Unit Testing, specifically, JUnit. The post began by explaining what Unit Testing is in programming terms and how Junit is a unit testing framework for Java and is tied into Test-Driven Development (TDD). The post explains the features of Junit focusing on how organized and simple it can be compared to other frameworks and testing methods. It specifically compares Junit testing to manual testing showing how tedious manual testing could be. It explains how annotations also work in Junit giving examples such as @Test and @Before while also explaining what they do. It uses real code to show simple tests being completed while also providing and explaining the outputs of each test. The post goes on to talk about the Junit rule which is a principle that works with Aspect Oriented Programming. It essentially means that Junit intercepts the testing method which allows the tester to manipulate things before and after certain test method executions. Junit can also provide a TestRule interface which allows the tester to create their own JUnit Rule for specification and customization.

      I chose this article because I found that I really loved learning about JUnit and wanted more information behind what it can do. I found that this blog post was important as a learning resource for me which made it more interesting to read. I was learning more about JUnit and its many other functionalities in testing which I previously did not know about. The post had a lot of information in it but used coding examples and definitions together to create a flow that read well and was understood much better. I enjoyed how it used these examples with comments and explanation within it to explain what was happening at each line of code. I was able to understand other uses of JUnit, specifically more about the annotations. I found that learning about the @Before and @After was very important to test methods and how they interact with the program while executing. The most interesting part of the post was the part where it explains how JUnit Rules work and how they can be customized using the TestRule interface. I found it very interesting that JUnit allows such customization for rules which makes it flexible as a framework. I thoroughly enjoyed reading this blog post as it did a great job introducing new concepts of JUnit in an understandable fashion while also refreshing the old concepts.

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

For my post this week, I found an excellent blog post by Martin Fowler on his personal website that details the “Test Pyramid.” The test pyramid is a way of representing the proportion of different tests you should be using for the purposes of keeping a balanced portfolio of tests.

As you can see by the pyramid, user-interface testing is slower and more expensive, moving to service testing which finds itself in the middle and then on towards unit testing which is speedier and less costly. This would imply that in general you want to rely more on unit testing than UI or service based testing, although all of these types of tests have a purpose.

Martin talks about the disadvantages of relying too heavily on user-interface testing. The slow testing increases build times and can require installed licenses for test automation software, which costs money and limits which machine the tests can be run on. The largest con Martin details was how brittle the tests were. That is, any small change to the system could break several tests and require them to be re-recorded. All these reasons show why the pyramid is the way it is, putting UI testing on the higher, smaller end. Fowler makes a point that often the usage of the high-level tests is as a second line of test defense. These tests are able to capture a bug you might have missed or not written tests for, and enables you to write a unit test to ensure the bug is taken care of.

I think the test pyramid is an interesting idea that highlights the importance of unit testing and helps define the priorities we should have as testers. Although it does not dismiss UI or service testing, it clearly demonstrates as testers that we should primarily be using unit testing to fix bugs in the code and make sure they stay fixed. High-level testing can be used to find things that are missed, but shouldn’t be relied on to catch bugs, and they won’t necessarily stay stable when you make changes to your program.

https://martinfowler.com/bliki/TestPyramid.html

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post I decided to share an informative post by Henri Idrovo on dev.to detailing the implementation and usage of the factory design pattern, specifically the “Factory Method.” Henri starts the blog by introducing the problem the factory design pattern is aiming to solve: using the ‘new’ keyword creates dependencies on concrete classes within our program. When many new objects are being created, this tends to get out of hand. Henri introduced the dependency inversion principle, stating “Depend upon abstractions. Do not depend on concrete classes.”

To show how to implement and improve your code using the factory design pattern, an example is introduced that involves a Pizza Store that has to create different types of pizzas. Without the design pattern in place, every type of pizza you would want to make would require another if-statement, so clearly something needs to be fixed. In order to use the factory pattern, we need to separate what is likely to change from what is not, and put what will change in a class of their own.

In Henri’s example everything that is common to pizza creation is placed in an abstract creator class, and the specifics are placed in concrete creator classes that extend the abstract class. Similarly, the different kinds of Pizza are each given their own concrete product class that extends the abstract Pizza class.

The factory method seemed hard to understand at first, but after going through the examples given in the blog it became clear to me, and the advantages of using the factory method are clear. By relying on abstractions instead of concrete classes, you are removing dependencies within your code and making it much more open for modification. Whereas prior to applying the method, the handling of creation of pizza objects was handled within the PizzaStore class itself, it is now handled within concrete sub-classes that can also handle different categories of pizzas. Also, personally it is easier to read the code of the PizzaStore class after applying the factory method, and it is much more clean in the abstraction. I can see the factory method being useful in any situation where you have to deal with the creation of a lot of categorically related but different objects.

https://dev.to/henriguy/design-patterns-factory-pattern-part-1-6k0

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Today I will be talking about a blog called “Unit Testing, How to Write Testable Code and Why it Matters”. This blog talks about the importance of unit testing for anyone who is a software developer. The blog talks about what unit testing is, what it consists of, and something that I had never heard of until today; the three A’s of unit testing:  Arrange, Act, Assert. We will talk about these three A’s of unit testing in more detail later. Another thing the blog talks about is unit testing vs integration testing. The blog sums up the difference between the two as unit tests have a narrow scope to test just one small part of the program whereas integration tests test how the “pieces” of code fit together and work hand in hand. Essentially, integration testing is a larger scale version of unit testing. So what exactly makes a good unit test? According to the blog, good unit tests consist of tests that are easy to write, readable, reliable, fast, and truly unit testing (not integration testing). This is where the three A’s of unit testing come into play. After you make sure that your unit tests adhere to the rules of good  unit testing, you can apply the three A’s of unit testing. The three A’s (as mentioned before) are Arrange, Act, and Assert. Firstly, we arrange. We do this by testing small portions of the code (unit tests) to ensure they work as designed. Next we give the test some sort of input to “test” its function to make sure it works correctly, this is also known as the Act phase. Lastly, we Assert what we know our output should be and we then compare it to the output of the function we are testing.

I think this is an extremely important article because it has given me a lot of insight on how to make good unit tests and how to make the testing cycle easier by remembering the three A’s of unit testing; Arrange, Act, Assert. I hope to use the three A’s of unit testing in my future programs in hopes that my testing will go smoothly and quickly. Another thing the article talked about that cleared up some confusion for me is unit testing versus integration testing. For me, the two have always been kind of interchanged and intermingled, as they are very closely related. I think that many people know there is a difference between the two, but do not know exactly what that difference is. It is good to think of it as integration tests being larger scale unit tests. In my head, I now think of integration tests as being made up of smaller unit tests, and seeing how those unit tests work together. I think this article was overall a really good read and will make my approach to writing tests for my programs change for the better.

Here’s The Link: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

In my last blog post, I briefly mentioned the idea of Test-Driven Development (TDD) as a process for creating programs, as well as its tying-in to Behavior-Driven Development (BDD). I wanted to learn more about TDD, so that will be the topic of this post! The article that I chose to read came from the following website: https://www.stickyminds.com/article/value-test-driven-development-when-writing-changeable-code.

This article touched upon concepts presented in both of the software development courses that I am taking (Software Design, Construction, and Architecture; Software QA and Testing). It highlighted the importance of making code that is easily changeable using techniques such as abstraction, encapsulation, or various design patterns. With this kind of coding strategy, developers don’t have to be as concerned about the whole program being affected when a few lines of code are revised. This is associated with more of the software design side of TDD. However, the process by which TDD takes place focuses on software testing, where further code is not written unless the automated and continuous tests produce a failing result. These tests are also written independently of the code being implemented. In other words, the code being tested is considered to be black-box, and the tests are made to uncover the failures in code, from which revisions will be made. This is where changeable code comes into play. This kind of coding mentality strives to ensure that the entire functioning of the program won’t break when the code is changed. This includes the automation of TDD; when the entire program is being rewritten because of a lack of changeable code, this may have additional effects on the testing process.

However, the article is quick to note that while TDD is a way to specify code behaviors by continuously testing and fixing code, it does not replace the process of Quality Assurance. With QA, the potential for code and tests to go wrong, as well as possible ways to navigate around these problems, are all considered. TDD is more “implementation-independent,” where the tests being run are not to assess the way behaviors are implemented in code, but in a more general sense, to simply express the behaviors that the program aims to implement. TDD, in a way, shows the specifications of a given program, and with continuous testing, can exploit the holes in a program so that they can be further improved.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

This week’s blog is about the four levels of software testing.  There are four main levels of testing that needs to be done before a program is ready for use: unit testing, integration testing, system testing, and acceptance testing.

Unit Testing

Unit testing is the first round of testing. In Unit Testing, the program is assessed with the focus on specific units or components of the software to determine whether each of them is working correctly. A unit can be referred to as a function, an individual program or even a procedure. The white-box testing method is usually used to do this kind of job since it is based on the analysis of the internal structure of the system or component.

Integration Testing

Integration testing, on the other hand, allows you to combine all of the units within a program and can be tested as a group. It is designed to find interface defects between modules or functions. It is very useful because it measures how efficiently the units are running together.

System Testing

System testing is the test ran after the application is actually completed and tested. The goal of this test is to check whether the system met all the requirements and see if it meets the Quality Standards. This test is done by testers that were not part of the development team. It is performed in an environment that’s somewhat the same as production. System testing verifies that the application meets the technical, functional, and business requirements that were set by the customers.

Acceptance Testing

Acceptance testing is the final test. This test basically determines if the application is ready to be released. During this phase, the users test the systems to find out if the application meets the business’ needs. Once this is completed, the application is ready to be delivered to production.

I find this blog interesting because at first, it looks like a really simple process to create an application and put it out on production but there are actually different levels to it. This has changed the way I think about software development. Just thinking about the process of testing the application, I could already see it having a great importance in software development. Also, you could be moving back and forth on the different levels of testing when the specification changes.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

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

https://dojo.ministryoftesting.com/dojo/lessons/testing-for-developers

This is the first time I’ve heard the ministry for testing’s super tester bros and from the Mario themed intro, I already appreciate the pure nerd culture of this podcast. They open the conversation with a discussion about a malware app, a clone of WhatsApp that tricked people into downloading spyware. This is a common problem, most searches bring up some kind of harmful software further down the results.

The conversation continues into various avenues revolving around security, particularly regarding a recent flaw in Apple’s sign in program. For a short period of time, anybody could sign in without credentials by clicking “Sign In” enough times with a blank username and password. This simple-to-use security breach is unexpected for a company as big as apple, since this is a type of problem could be avoided by better testing and coding.

At the 19:30 mark, they brought in two developers to talk about how they work with testers. Although the target in a dynamic software development environment is to release the product in working order as quickly as possible, they both express that there is a lot more value in collaboration over rushing. The quality of the end project doesn’t depend solely on the tester or the developer alone. Having a tester by the developer to share insight and do some “peer testing” will also help the developer understand how the further processes work, so he may be able to design around them. This will help save time in a project, since the developer wants the code to pass, or at least not fail, on the first few attempts after handing it to the tester.

Towards the end of the podcast, the hosts shared stories about encounters in their career. A typo was detected on the front page of a company that one of the hosts worked at. At the time, this error was given a low priority score since it didn’t actively change or effect the working order of the website, however, he reflected on how many people saw that typo and immediately disregarded the website as worthy of doing business with. In that way, this small error was in fact very high priority and greatly changed the effectiveness of the website to bring in customers in a way that had nothing to do with its true functionality.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

http://news.mit.edu/2018/model-helps-robots-navigate-like-humans-1004

A paper describing a model where researchers combined a planning algorithm with a neural network that learns to recognize paths that lead to the best outcome, then use that knowledge to guide a robot through an enviroment.  The researchers demonstrate their model in two settings, navigating through rooms that have traps and narrow passageways or navigating through a room without any collisions. This learns by being shown a few examples of similar eviroments and then bases its actions on that. For example, if it recognizes a door it will know to exit through it based on the learned examples all exiting through a door. This model combines older, more common methods with this new look at machine learning. The planner creates a search tree while the neural network mirrors each step and makes a prediction based on probabilities for possible actions to take. If the network has high confidence of success it will act on it, otherwise it will fall back on exploring the enviroment like the tradititional method. One application for this model is autonomous cars where there are multiple agents all operating at the same time in the same space. For autonomous cars intersections and especially roundabouts are extremly challenging since there are numerous cars moving around a circle going in and out all at once. Results indicate that this model of machine learning can learn enough behavior based on previous experience to be able to navigate something as that challenging. In addition, they only needed a few examples of very few cars in a roundabout to be successful.

I find this article to be interesting since autonomous cars are going to be extremely popular in the future. This model is another advancement toward getting self driving cars even more independent to the point of something from a sci-fi movie. In addition to that, having something to efficiently navigate a room is important for other applications such as assisting somone that is blind. Something like this could give someone who has to rely someone else more independance if all they need to do is wear some glasses that tell them where objects in the room are located and how to navigate around them.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

In this Apprenticeship pattern “Emptying the Cup: The Deep End”, it explains on how you as a developer can further your development skills by taking on challenges that may or may not involve risks. Even though there may not be risks that can affect your career as a software developer, it may cause you to fail the challenge or objective you are trying to accomplish. Of course in any industry of work that you may wish to advance or climb the ladder in, you have to tackle on bigger tasks to show that you have the skills and mindset to be in a bigger and better position than the one you are currently in. However, failure can result in the process. The Apprenticeship pattern “The Deep End”, highlights that failure is normal when taking on challenges.

“This has risks. If you get it wrong and end up over your head you could drown. Thankfully there are many places in IT where you can take risks without destroying your career if you fail. Risks are opportunities seen through the half-shut eyes of fear. This doesn’t mean lying on your resume to get a job you can’t do, nor does it mean tackling challenges without adequate preparation. Instead, it means taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.”

Drowning in this context means failure and I completely agree with this idea because as an individual, I learn best by failing and making mistakes. At times, I can be scared to fail but I know deep down it is the best way for me to learn. This pattern also reminded me that feeling fear is okay when you I think failure is staring me right in the face because the after effects of failure is more of a gain for me when taking on a challenge than being successful on a smaller, simple task. After I fail a challenge, I reevaluate what I did wrong so I can approach it differently the next time I take that same challenge head on. This concept of taking on “The Deep End” isn’t only important in Software Development but it can be applied in any workplace.

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.