Martin Fowler’s Blog is an amazing resource for someone breaking into the field of Software Development — his blog posts are extremely easy to read and are very educational. Even older content is still relevant and helpful to read through, like this article on the reasoning and design decision behind JUnit tests creating new instances for each test. As someone who has only a bit of experience writing my own Unit Tests, this was pretty eye-opening.

So why does JUnit create a new instance for each test, and what does that even mean? Each time you run a test, a new instance of each object used in the test is created. This means that in one test, if you create an object or assign a value, that change will not carry over into any other tests. The idea behind this is called isolation, and although it may seem counterproductive, it is extremely important. It ensures that no test should ever do something that would cause another test to fail.

So what exactly makes isolation so important? The point of Unit testing is to bend and stress the basic structure of the source code. If all tests were relying on a shared state which was dynamically changed between one another, each would leave behind data that would impact the other tests. You’d end up testing not just the source code, but you’d also be dancing around the different tests you had already written. If each test weren’t isolated, it would make the main objective — testing the product — significantly more complex.

JUnit in particular provides functionality to support this isolation and make the job of the tester easier — things like the setUp method. If you want each test method to create an Array with 5 elements, you would place that in the setUp method for it to be run prior to each test as opposed to having to rewrite that piece of code for each test you have. This helps keep each test isolated, whilst still providing every test with a shared base state from which to run.

If you’re like me, you had encountered this problem while tinkering around with JUnit and kind of accepted it without questioning the purpose behind it. It’s intuitive and makes sense that each test should be isolated from the others, but it is also important to ask “Why?” or “What would change if this were different?”. It gives insight into the JUnit framework, and helps make a more effective tester.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

https://www.infoworld.com/article/3305326/application-testing/for-agile-testing-fail-fast-with-test-impact-analysis.html

Regression testing is testing a piece of software to make sure any changes or additions have not broken any existing functionality. In agile development it is important to release your product as quickly as possible and because of that it is important to fix any failures quickly and efficiently. Developers need feedback as soon as possible but regression testing can take up to days to complete, so they often settle with CI or scale down testing. As a result, productivity is worse and the close to the deadline sprint is more painful. One common approach to speeding up regression testing is to remove end to end testing which causes developers to miss a lot of issues that have a very large impact on the user experience. Risk-based testing is another way organizations speed up the process but many believe it can require too much overhead. However some amount of risk-based testing has to be done in order to guide prioritization on what needs to be worked on.
Test Impact Analysis is a technique that rapidly exposes issues in code since the last time it was modified and tested. It does this by correlating all regression tests to code and select only the tests associated with the latest round of changes. It then orders those tests based on their likelihood of detecting problems and prioritizes the execution of the ones most likely to expose problems. This helps you find a majority of the problems in an extremely short amount of time. This also results in much tighter feedback loops which means failing builds get resoled faster. Test <> code correlation makes it easier to determine where additional tests need to be taken as well as streamline the defect remediation process. Test impact analysis can be applied to any test including unit tests and automated functional tests. With test impact analysis a specialized set of cases is selected and executed. Static analysis finds which code has been modified since the previous test run, then dynamic analysis correlates the regression test suite with the identified code and regression tests that do not touch the modified code are eliminated for the test run. Additional analysis is then run to determine which tests are most likely to expose a defect in the new code and then sorted so that the test most likely to expose the most problems is executed first then merged correlated code coverage from all of the executed tests is visualized versus the new or modified code map, making it simple to spot coverage gaps.

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.

Hello again, readers! Today I dove into an article by Peter Wayner detailing 5 different design architecture patterns for software design and their benefits and weaknesses.

The first is Layered architecture. This is where data enters the top layer and as it passes through each layer, the layer performs a specific task. A major benefit is that each layer is maintainable, testable, can easily be assigned roles, and are easy to update and enhance. However, this can result in the source code being very messy, the code can be slow, the whole program can be hard to understand, and changing a small part could be impossible as you may need to change the whole program.

The second is Event-driven architecture. A central unit is built that accepts all data and then delegates task to separate modules to ensure that your program isn’t just waiting around for something to happen. This allows for the program to be scalable, adaptable, and easily extendable. This can lead to complexity when testing and error handling can cause troubles in development. Essentially, the more each module is dependant on the others, the more troublesome the entire program becomes.

The third architecture is Microkernel architecture. This architecture uses a set of core operations that are repeated over and over again in different patterns depending on the data given. If needed, different modules can be tacked on to allow the program to perform different functions and patterns. The difficulty with this architecture is that getting the plug-ins and microkernels to cooperate can be tricky. There is also the trouble of not being able to modify the microkernel once plug-ins start to depend on the microkernel.

The fourth architecture is Microservices Architecture. The main idea here is to build a number of different tiny programs that will handle one specific task instead of having one big program do everything. This also allows some individual programs to be scalable up to a large size while others are kept small. Some downsides are that some tasks can’t be easily split up into a single microservice. Each microservice must also be independent or the cloud can become unbalanced. Lastly, if tasks are split up amongst several microservices, the communication costs can begin to skyrocket.

The final architecture is Space Based architecture. This architecture is designed to split up processing and storage between multiple servers. This protects against collapse under a great load. Data is stored across the nodes and information stored in RAM. This does make many simple tasks quicker but can also slow down computational tasks. This architecture can also be referred to as Cloud Architecture. The main drawback with this is that with RAM databases, transactional support is difficult. Testing the entire system can be difficult as well.

This was an interesting read as it went one step higher than what we learned in class so far. This covered the upper level where multiple programs come together while in class we cover designing a single program. The Space Base architecture was quite familiar as I learned about it in a Cloud Computing course I took earlier in the year that dealt with Hadoop. The Microkernel architecture was cool as well as I personally use Eclipse to work on in-class projects and learning more about its overall architecture is something I thought I would never dive into. The Event-Driven Architecture has given me an idea for a way to work on the final project that was recently assigned to us in class. Hopefully, it works out as putting something you learned to use is always a rewarding experience.

Until next time readers. Have a wonderful day and see you next week!

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

As I take another step towards Software Quality Assurance Testing. I decide to research I topic discuss in class the other day. The topic being Mocking in testing using mockito. For this blog I will be talking about a blog that relates to my topic of interest. It’s name is “What is Mocking in Testing?” by Piraveena Paralogarajah.

This blog was very interesting and does a good job introducing to readers what mocking is and why it is used. I suggest this blog to readers with no experience or knowledge to the software framework known as mockito and/or the mocking concept.

A brief summary about the blog “What is Mocking in Testing?” by Piraveena Paralogarajah.

What is mocking?

Mocking is the notion of making “a replica or imitation of something”.

Where and why is mocking use?

Mocking is used in unit testing. It is used on object that depends on other objects in order to isolate the object by having it mock and simulate the behavior of the original object. Mocking is done using general types of mocking frameworks. A few of these framework mentioned by the blog are the following:

• “Proxy based ( eg: EasyMock, JMock, Mockito)”
• “Byte code Manipulation / Classloader remapping ( eg: jMockit, PowerMock)”

What is Proxy based Mocking? How it works?

“A proxy is just an object which will be used instead of the original object. If a method of the proxy object is called than the proxy object can decide what it will do with this call:

• delegate it to the original object
• handles the call itself”

The blog goes on and list the limits of Proxy and the fact that “proxy does not require an instance of an interface /class if the proxy handles all method invocations itself”.

What is Classloader remapping based Mocking?

Is the notion of telling “the class loader to remap a class reference to the class file it loads”.

ALL QUOTES ARE FROM THE BLOG “What is Mocking in Testing?” by Piraveena Paralogarajah. 

I enjoy the blog and also learned that there are other types of mocking frameworks not just mockito which I will have to look into more. That being said if you take the time to read the blog I am blogging about you will get more detail information on what mocking is and why it is used and a few other mocking related details such as the general types of mocking framework.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Angular Unit Testing

For this week’s blog post I thought I would take a look at Angular Testing considering in class we have been discussing it and are going to use it for our final project. From the site I found they go into great detail as why it is good to use angular and overall how to conduct it properly. They first start off by listing an example of code that complies properly and “works” but under a more complex situation with dozens of tests in a suite it may begin to fall apart. They go on to explain that for every run it will recompile the components and operations taking up to 75% of your time recompiling and not actually running the tests themselves. Next, they show an Angular Testbed monkey patch that will patch the testing framework resetting the testing module before each run and each test. The TestBed.resetTestingModule function they use will clean up all the overrides, modules, module factories and disposes all active fixtures as well, essentially cleaning up what you have. A _initIfNeeded function then comes into play , preserving the factories from the previous run doing what they need to do. If the flag is false the TestBed function will re-create components required for the test, creating a new zone and testing module but not recompiling anything if moduleFactory is in its correct place. After this they run the code they have, clocking in at a 24 second run time to complete its test suite. Then they apply the patch by calling a setupTestSuite function and replacing beforeEach with beforeAll causing the run time to become 8 seconds. A notice 3x time increase in time efficiency for this certain example. With this patch it allows them to preserve the compliation results and re-use them for multiple test per suite.

After this they start up Karma parallel tests, allowing for the tests to be run in parallel. This website shows all the code which is quite lengthy and I wouldn’t want to subject you all to a blog post that takes up too much space. By clicking the link below you can see all the code they have and more. All and all this website was pretty handy and interesting with what they described and how to show angular to its potential.

https://blog.angularindepth.com/angular-unit-testing-performance-34363b7345ba

From the blog CS@Worcester – Matt&#039;s Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.