http://misko.hevery.com/code-reviewers-guide/flaw-constructor-does-real-work/

This blog post talks about why having a constructor do too much work is a bad programming practice. When a constructor instantiates and initializes its collaborators, the result is often inflexible and can shut off the ability to inject test collaborators. The author gives a few reasons why this is a flaw:

• It violates the Single Responsibility Principle – Mixing collaborator construction with initialization suggests that there is only one way to configure the class. Having object graph creation take place in the constructor violates the Single Responsibility Principle
• Testing directly is difficult – If a constructor does a lot of work, you will have to do that work when creating the objects while testing
• Subclassing and overriding to test are still flawed – When you use subclassing you will fail to test the method that you override
• It forces collaborators on you – You don’t always want to create all an object’s collaborators when you test it

Signs that a constructor is doing too much work:

• new keyword in the constructor
• Static method calls in a constructor
• Object not fully initialized after the constructor finishes
• Conditional or looping logic in a constructor
• Complex object graph creation in a constructor rather than using a factory or builder
• Using a initialization block

Fixing the Flaw:

To fix this flaw you should remember to pass collaborators into your constructor rather than create them there. The responsibility for object graph creation and initialization should be moved into another object such as a builder, factory, or provider. These collaborators can then be passed into the constructor.

Overall, the phrase “work in the constructor” means doing anything that makes instantiating your object difficult or introducing test-double objects difficult.

I thought that this blog did a very thorough job of explaining why doing work in a constructor is a flaw that should be avoided. It did a good job explaining why it is a flaw, recognizing when it is happening, and explaining various methods to fix it. There are also a lot of code examples that demonstrate the problem more concretely and show how it can be fixed. After reading this blog I now have a better understanding of what should and should not be included in a constructor. This blog also introduced me to some new object-oriented programming concepts that are too specific to be covered in the classroom. Overall I thought this blog was very informative and I expect to use what I have learned in future programming projects.

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

Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.

Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

• static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
• relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
• absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
• fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.

Source: http://blog.teamtreehouse.com/css-positioning

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.

Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?

Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.

The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.

CSS Positioning Blog

In the blog CSS Positioning: A Comprehensive Look, Louis Lazaris discusses the main types of positions used in CSS’s position property. The positions are:

• static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
• relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
• absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
• fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.

The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.

Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.

The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.

Source: http://blog.teamtreehouse.com/css-positioning

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

In this article, Greg Sypolt talks in brief about the role of AI as a software testing assistant.  I chose this piece because it combines a field I’m interested in (AI and machine learning) with the content of my software testing course.  I am interested in AI task automation already, so a piece that dovetails these two topics is a perfect fit.  The author has chops as well — he oversaw the conversion from manual to automated testing at his company, and offers training to help other teams transition to automation.

Sypolt starts off by outlining three uses of AI in testing:

1. Automatic test case generation that reduces level of effort (he abbreviates as “LOE”) while maintaining consistent standards.
2. Generating test code or pseudocode from user stories; a user story is a use case or use sequence for some kind of product (software or hardware).
3. Codeless test automation, or testing without writing tests as code.

He then outlines the necessity of properly training the testing bots, and some of the difficulties that may be involved:

1. Identifying the proper training algorithms.
2. Collecting a massive quantity of useful data.
3. Ensuring that bots behave in a reasonable fashion from a given set of inputs, and ensuring that they exhibit new behavior (generate new tests) when the inputs change.
4. The training process never really ends; each new set of tests and results gives the bots another data point to learn from.

I firmly believe that we are at the very start of a revolution in machine learning.  Why not apply those principles to software testing?  There are, of course, a couple of issues that arise which Sypolt didn’t mention: quality of tests and accuracy of tests.

A point firmly pushed by other articles and texts I’ve read is that quality is more important than quantity.  There can be little difference between running ten tests and running one hundred tests if the extra ninety don’t teach us much of anything.  The trick isn’t to create an AI that merrily runs thousands on thousands of unit tests; it’s to create on that identifies the important tests which reveal faults we don’t know about and confine itself to executing exactly those.

It’s also very important to ensure that the AI has learned properly and is up to standards — and that means testing the AI.  Which means testing the AI that tests the AI, and it’s digital turtles all the way down.

I can take away from this article two things: Firstly, it’s reasonable to combine two fields that I’m interested in (AI and testing) and that resources exist or will exist to support the two together.  Secondly, the field of testing is constantly and rapidly changing.  Additional learning is crucial, just like AI systems continue to learn from each new piece of data.

Article link

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

With this semester coming to a close, I thought it would be appropriate to write about our most recent topic discussed (code review) and compare it with something widely covered during this course: unit testing. I found a great Codacy blog to aide my exploration of the similarities, differences and importance of these two topics.

Codacy explains that code review generally means to manually inspect the code, whereas unit testing is implemented to automatically detect bugs within the code. It seems to me that unit testing is focused solely on finding malfunctions (bugs) in a product, whereas code review considers the overall style, readability and functionality of that code as well.

Rather than asserting that one is superior to the other, Codacy suggests that both code reviews and unit testing ought to be done in all software projects. I feel software developers can produce efficient and supreme quality products when appropriately combining the two techniques. Thus I have to agree with Codacy regarding the implication that unit testing should not replace code reviewing, and vice versa.

The blog author gives a great example of why unit testing alone should not replace code review. It seems that there was an actual situation that occurred where a vast series of unit tests were run to ensure the integrity of a very important governmental system. But when the program was scheduled to go live, it failed to run. It turns out that the system was scheduled to launch on a Sunday, but the unit testing team only worked weekdays, thus unit tests were not run on the weekends. For one reason or another, it seems that code reviews had failed to be conducted for this governmental system.

My takeaway from the scenario described above is the fact that code reviews should have certainly have taken place. This is because I feel that code reviewers, through proper analysis, could have identified there was a flaw within the code that made the system inoperable during Sundays. Examples such as this solidify my belief that human analysis should be coupled with computerized testing. In a sense, code reviews “double check” the work of automated unit tests.

On the other hand, I also agree with Codacy in the sense that code review should not replace unit testing either. In regard to automated unit testing, computers generally have the capacity of identifying bugs at a speed that far exceeds the capability of the average person. Trying to manually replicate the work of automated tests in this sense just seems inefficient to me.

I found Codacy’s blog regarding “Code Review vs Unit Testing” to be engaging and informative. Based on what I’ve learned from the real world examples given by Codacy, I feel that code reviews and unit testing are equally important. My goal is to continue to learn and improve my expertise in code review and unit testing. I am confident that I will need both of these skills during my professional career.

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

The article this blog post is written about can be found here.

I chose this article for this week because I was curious about integration testing, as most of what we’ve done up until now has been unit testing.

Integration testing, broadly speaking, is defined as testing used to determine if the connection between two systems work. Systems can be a lot of different things – different parts of the code in one software product, multiple software products working together, your code and a database, a database and the internet, etc. Sometimes individual pieces can work fine on their own, and yet the whole breaks down once they are combined.

The article offers a scenario where someone takes a picture, uploads it to twitter with a caption, and sends the link to a friend as an example of where faults discovered by integration testing might be found. If one of those steps fails and the tweet never shows up in TweetDeck, testing would have to be done to determine where in the chain of connections the fault lies, and then what specifically went wrong within that connection. The article suggests starting this process by reviewing the log files, which should offer an indication of how far the tweet managed to get.

The article gives electronic health record systems as another example of complex systems where integration testing is needed. There are about 20 different popular EHR systems in use, as well as ones created by healthcare companies, which all store data in one way and send it out in a different way. Records go out to insurance companies that want to receive them in different formats. There isn’t one record to represent all the medical information about one person, but scattered records containing different information based on what each party needs. This situation demands thorough integration testing of the connections between the EHR systems, billing companies, and insurance companies. With so much that varies, there’s a lot of opportunity for failure.

Reading this article helped me understand the different scales on which integration testing operates, and that I can’t think of a piece of software as existing by itself – it’s going to interact with others’ code and with elements in the outside world. It’s necessary to consider not just the software itself but the bigger picture. With this in mind, I will think about the ways in which my code interacts with other components and have an idea of where to start testing those interactions.

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

A recent blog post from Cigniti discusses the importance that Agile Testing has in enterprises (http://www.cigniti.com/blog/agile-testing-really-helpful-enterprises-stay-innovative-competent/).  The post does not argue whether or not Agile Testing is essential for enterprises, but instead discusses why it is essential for enterprises to employ this method of testing in it’s daily operations.   It is becoming increasingly clear that their are many benefits to incorporating Agile Testing in their enterprise.  Enterprises need to be flexible and able to change in order to stay competitive and try to keep an edge over rivals.  One of the biggest and most obvious advantages of Agile Testing is the flexibility it provides to not only the testing team, but all teams involved.  The short sprints that Agile Testing provides allows companies to adjust their goals quickly and easily if the customer or the development teams changes their desired outcomes.  This is essential to businesses that want to maintain an advantage over other companies and stay attractive to clients.  Agile Testing also helps improve the overall customer experience.  The flexibility and constant ability for change helps a business adjust to a customer’s inevitable desire to change their minds on what they want from their product.  Agile Testing also helps the testing team and development team communicate more and relay information back and forth to work with each other rather than against each other.  While there is always risks in producing a product Agile Testing greatly cuts down on these risks.  Being able to stay in constant conversation and working in sprints it allows teams to catch and resolve issues as they arise.  Companies can then adjust time frames as well as end user products in a timely manner rather than waiting until closer to the release date and having to push the launch back completely or risk losing the contract with the customer.  These all boil down to communication between all teams involved on the project.  Without proper communication Agile Testing falls apart and loses much of its efficiency.  It’s important to realize that the completion of a quality product that satisfies the customer’s needs is more important than the pride of any individual or team involved.  Programmers should be ready and willing to bring up any issues or faults that are found as well as be receptive to any constructive criticism from other team members.  This allows Agile Testing to work effectively and efficiently throughout the entire development process.

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