For this week, I read an article called “JUnit Best Practices” by Kyle Blaney. The article talks about how to use JUnit in the most efficient way and get the most out of the tests. The two main goals of unit testing according to the article are making sure tests are “extremely fast” and “extremely reliable”, meaning your tests should run as fast as possible while also producing correct, reliable results. The article then goes on to point out a number of different important practices when doing unit tests. Some of these practices are ensuring unit tests are running completely in-memory (tests should not read from the filesystem), not skipping unit tests, aiming to have each test only test one thing, using strong assertions, and much more.

I thought the article was extremely informational and very useful. We will be looking at unit testing in CS 443 this semester and having this information should help me produce better unit tests, whether they be self-written or just by using JUnit in the most efficient ways possible. I found it useful that the article mentioned doing things such as using the strongest assertions possible and making sure your tests are reliable. Having strong assertions will mean that if the unit test passes your assertion, then your code should hold up in the long run. However, none of this matters if your tests are not reliable and do not produce correct results. So making sure your tests are reliable is a huge part of the testing process. With the combination of correct, fast tests and strong assertions, your unit tests should be very strong. I like this idea of having strong unit tests because if my code can get through the strongest, hardest tests then my code should be very strong overall.

I agree with all the points made in the article, and I hope to use the information presented to me in the article in the future when I go to do unit testing. I would like to see how applicable these practices are in real life testing and see if they all hold up like they are supposed to. I am looking forward to unit testing because I now know some very important aspects to look out for.

Here’s the link: http://www.kyleblaney.com/junit-best-practices/

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 this episode (number 219) of “Test Talks,” I was able to hear Shailesh Rao’s insight into having quality software. He compared it to a “paper-free office” or a “stress-free life,” both worthy goals, but are hard to achieve. They can be strived towards, but it is near impossible to get it 100%.

He brought up the issues that bad software can pose to potentially millions of users. Bad software can open the doors to hackers, who might be able to take down websites like Twitter or Reddit. Also, it might stop airlines from being able to function — an annoyance to most, but Mr. Rao asked, “what if there was time-sensitive and lifesaving medicine onboard?”

I found this podcast brought up some aspects that I had not thought of before when if comes to quality assurance. I suppose that I’ve thought about the various things he brought up, but as a consumer and never as a creator of the software.

A very thought-provoking topic brought up was the fickleness of consumers. They don’t have the patience to put up with a buggy app. They will move on to the next thing. It is easier than ever to launch a software project to a very wide audience, and it’s become apparent to me that it should be done right the first time around because customers don’t always give a product that flopped a second chance.

Another point brought up that will affect the way I think about testing and quality control is that you should test for all possibilities or you might not know the market you missed. People often say to themselves “it won’t happen to me,” and think their software will not be downloaded millions of times, but if they didn’t prepare for those conditions, they won’t get that chance.

The core message that was hammered home was that developers should have quality at every step. With as complicated software can be, it is extremely difficult to have it be truly bug-free, but it is possible, and we should always strive to be as close to it as we can.

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

http://thetesteye.com/blog/page/3/?utm_source=fuel&utm_medium=referral&utm_campaign=lrfuel

I’ve been delving into the writings of Rikard Edgren, a software tester who writes blog posts on thetesteye.com. I think its useful to see what professionals think works well, so today I’m talking about his post titled “ISO 29119 – a benevolent start” which I’ve provided the link to above. Although this post was written some time ago, I believe it provides general foundations of what a test system should include.

He first states that he tries to see the good in a system first, so a lot of the writing that follows is of appreciation for what this system does right in his opinion and provides suggestions for concepts that should be included in further systems. Edgren breaks down his thoughts about the testing standard into three parts, concepts and definitions, test processes, and test documentation.

Regarding the definitions of the system, Edgren compliments the simplistic terminology used in ISO 29119. Compared to other testing standards, this one is more flexible while also limiting multi-faceted words. He also appreciates the use of Diverse Half-Measures in order to cover all the bases in terms of test coverage.

The test process for ISO 29119 prioritizes testing strategy, which gives way to multiple advantages. For instance, it ensures that important goals are followed, met, and easily communicated for the future. The feedback is also more detailed rather than just a simple pass/fail. Additionally, this is a hopeful sight for test standards to come, Edgren is excited that testing strategy is starting to become more common and more of a priority going forward.

Finally, Edgren praises certain aspects of the test documentation, which incorporates concepts from both traditional and agile projects. The importance of this being that previous documentation concepts don’t have to be set in stone for future projects, breaking traditions is sometimes beneficial. Edgren makes the point that the documentation should also have the stakeholders in mind, so diagrams and simple explanations could go a long way. Bridging the gap between tester and employer is vital, it is very important that both parties are on the same page regarding the results of testing.

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

I decided to focus on the pattern involving feedback loops this week, because I saw it being referenced in many of the various other patterns throughout the text I browsed. Also, because it seems like to be a good apprentice, having lots of feedback to see what one is doing right or wrong seems like an incredibly important step.

The pattern is called Create Feedback Loops. The idea behind it is incredibly simple, but strong. Make sure to set up mechanisms that will give you concrete feedback on how you are doing. There are many various possibilities, from purely technical such as test-driven development to simply asking others for honest criticism of what you have done.

However, make sure the feedback is examined and the good feedback that can be implemented is taken, not bad advice that can set you back in the disguise of feedback. It is important to have positive feedback that encourages you to keep doing good things, and balancing feedback which discourages bad things.

I have realized the importance of concrete feedback implicitly throughout the years, but having it cemented as the important step it is and being explicitly aware of it, I feel, will make things going forward much easier for me. I have experienced the feeling of being completely lost many times and see how good feedback loops would have prevented many of these instances.

I was nodding my head the entire time reading the section on this pattern. Everything stated made sense and I could relate to. The personal story of Patrick’s situation was something I’ve felt many times in and out of software, where any feedback you get is vague at best and it feels impossible to know where you should head or do. Unfortunately, this was a situation I faced with some courses and professors, where after a discussion or question and answer session, I felt like nothing was clarified or it was even less clarified. These situations sometimes worked and sometimes did not, but I was always left with the sense that I did not learn much.

Going forward, I will attempt to avoid this from happening as much in the future as possible by using the techniques and actions the text suggests.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The “Unleash Your Enthusiasm” pattern from Chapter 2 of Apprenticeship Patterns was interesting to me, because I hadn’t previously thought about what an apprentice might be able to add to a team. I didn’t even really consider that there were things an apprentice could add to the team, apart from the promise of future skills acquired during their time as an apprentice. But according to this pattern, the enthusiasm of the beginner software developer is a valuable asset, as it sparks the enthusiasm of the more experienced developers on the team. The authors encourage you not to suppress it in an effort to blend into the status quo, and in fact assert that it’s an apprentice’s duty to bring their enthusiasm to the work. Moreover, apprentices are comparatively blank slates who are more likely to suggest creative new ideas that developers with more entrenched habits wouldn’t think of. These should be shared instead of held back out of fear.

I did disagree a little bit with their statements about unwelcoming environments, which seemed to undermine their overall point. The last thing someone who’s unsure about sharing their excitement needs is to have it suggested that they’ll be secretly looked down on for it. Even in groups that don’t seem hospitable to a newcomer’s enthusiasm, there might be more inconspicuous ways of introducing it. Maybe enthusiasm can be shared with individual team members that seem open to it. The group’s status quo could be slowly altered from more private morale boosts, but even if it isn’t, you’ve still shared your excitement with someone. And maybe that’s a bad idea for reasons that aren’t obvious to me yet, but as an apprentice with no preconceptions, it’s my responsibility to share maybe-bad ideas.

After reading about this pattern, I have no doubt that it will come to mind in situations where I feel self-conscious about my enthusiasm and suggestions. I’ll have the ability to recognize now that it’s one of the few commodities I can offer my teammates, and that it won’t last forever, so I ought to use it while I can instead of restraining myself for the sake of pride.

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

In this post, I will be covering the “Study The Classics” pattern from chapter six. I chose this pattern because it’s title seemed interesting. This pattern is contained within the chapter that focuses on individuals who are not necessarily motivated by learning for a grade, but those who are motivated by knowledge growth. So, this… Continue reading Apprenticeship Patterns: Study The Classics →

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

The subject of this blog post is the first chapter of “Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman” by David H. Hoover and Adewale Oshineye.  I found this to be a phenomenal read and I am excited for what the book has to hold.  I now officially consider myself an apprentice software developer; I feel that I possess many of the values that Hoover and Oshineye use to define good software craftsmanship, which has reinforced and revitalized my feelings toward my field and abilities.

I really appreciated that this first chapter was devoted to defining key terms and concepts that will appear throughout the book.  I think these definitions will help me better grasp the concepts and and overall goal of the book, as I continue reading it.  I did not really consider myself an apprentice, until I read the definition provided in the book.  Marten Gustafson, an interviewee from the book, defines apprenticeship as being in the “state/process of evolving and looking or better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways”, which I believe is the state of mind that I am currently in.

Something that really resinated with me, from Hoover and Oshineye’s definition of an apprentice, was the part where they talked about the need to learn how you learn and grow effectively, and how this inward focus on yourself and your need to grow is the essence of being an apprentice.  Up until now, I don’t think I was allowing myself the kind of inward focus they are describing – which is something I want to change.  I now feel that I truly am an apprentice and, as such, I ought to be a little more focused on myself and my progression toward becoming the master developer that I hope to be.

I also really appreciate Hoover and Oshineye’s understanding that the readers of this book will come from all different kinds of situations and circumstances, and they often reiterate the fact that the purpose of the book is not to dictate the right courses of action but to shape your mindset to that of a good software craftsman – “Since most newcomers’ experiences do not resemble the ‘ideal’ apprenticeship, the modern concept of apprenticeship is mainly a frame of mind: you recognize that you are still at the beginning, even if you’ve been programming for several years, and you are prepared to take steps to create your apprenticeship out of the circumstances you are in”.  I really connected with this because, I have been programming for years and have never considered myself  a true apprentice – because I wasn’t.

I have realized that, even though I have a bit of experience, it does not by any means make me an apprentice or software craftsman.  But, I am now prepared to take the necessary steps to create my apprenticeship, and work toward not only becoming a master developer but a master software craftsman.  I am excited to continue learning from this book and I look forward to the journey ahead of me.

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