This weekend I have begun reading a fascinating book called Apprenticeship Patterns by Adewale Oshineye and Dave Hoover as part of my software development capstone class.
As I was reading through the first chapter, my initial impressions were this book would be helpful but I found it surprising that the authors state there is an actual “need” for books such as this one in order to be successful as new software developers. Before reading this, I was sort of under the impression that entry level positions would be more friendly to new developers with other more experienced developers helping you along the way. I also found the quote from Pete McBreen to be rather surprising too, I never thought there was an “abundance” of developers, as most articles you read tend to give off the impression there isn’t enough software developers. This first chapter and the way this book is framed in the idea of software development being an apprenticeship has certainly begun to change the way I am thinking about the field and how its not just a job but a lifelong journey.
This section from the first chapter also has begun to change my thinking in how I view my early jobs in software development. I never really thought of the first job you have as a developer in terms of focusing and learning for yourself, I have always thought of it as starting position and performing a task for a company, but I do like this idea of “selfishness” in the beginning.
Chapter 2 seems like a good chapter to start with in this book and will be where I begin with reading and learning about the various patterns. I particularly like the idea of learning how to sort of reset yourself to be able to learn new information from others who are more experienced than you. I find this chapter’s introduction to be especially relatable as in learning I strongly prefer to listen rather than talk so I think chapter will have some good patterns to learn from to further strengthen my learning skills as a listener.
I am also interested in reading Chapter 3, as I find the story of Dave very relatable with having only a small amount of knowledge at the beginning and finding it daunting to know there are others who know so much more than you and how to learn from these people, especially during the beginning of your career.
I want to read Chapter 4 as I agree with the message and want to learn how to strive to continuously improve as a developer instead of becoming complacent and satisfied with the current knowledge of a skill.
Finally, I want to examine Chapter 6, especially with the idea of learning more by reading books and how to do this with regards to software development. In particular, I hope the patterns in this chapter helps elaborate how to find the time and motivation to do so when it is no longer “assigned reading”.
Overall, I am excited to begin diving into the patterns in this book, particularly the ones in the earlier chapters as these seem like they will be the most helpful to me right now with where I am as a developer.
After reviewing the various links posted on the main LibreFoodPantry website I think the most interesting item to me was the “What’s New” page. I really like the concept of this page and as someone who has been following the project for the past couple of months primarily through Discord notifications, I think it is extremely useful to have a page on the main website that highlights important changes in plain text versus a bot posting GitLab events through Discord. I am a bit surprised there isn’t more on this page yet, given the many new changes to the organization of projects I saw yesterday in the first CS-448 class. I also wonder how this page is different from the announcements channel in the Discord server.
This week is the beginning of the spring 2020 semester and the last course of the software development concentration, CS-448. I am excited to finally be working as a developer on one of the LibreFoodPantry projects and can’t wait to get started!
Article link: https://dzone.com/articles/why-you-should-stop-now-testing-every-class
A great article I read today goes over the importance of creating the correct kinds of tests for software. In this article, the author thoroughly explains the importance of testing the “behavior” of software versus “implementation details” and how not “every single class” needs to be tested. I think the author does a great job with both an easy to understand narrative and tons of example code that illustrate the importance of testing that software performs to specification versus testing how the code is written. The example code given in the article goes further with linking to an entire GitHub repository for the example code (which elaborates beyond what is shown in the article) which I really appreciate as it lets me see exactly how this concept aligns with a complete program. The most interesting part of this article for me was in the author’s explanation of how refactoring code can cause tests that are written (incorrectly) to a specific implementation to fail. I think it is important to see this point that putting in extra effort in developing software but on the wrong things can actually do more harm than good further down the line. Especially as the author points out if you were to further refactor the code and change how it works (even return types as the author demonstrates!), this causes bad tests to fail, which only creates even more work. I never really thought of how refactoring could create more work in a testing scenario before reading this, but I like how refactoring further helps the overall program by exposing the appearance of useless tests. One other part of the article I really enjoyed was the side narrative the author gave while working through his example of how the steps they took followed TDD (test-driven development). This is also something I wanted to learn more about, and this article also provides a good example of TDD by explaining how certain practices taken in the code example adhere to the rules of this methodology.
Overall, I think this article covered an important topic well, and serves as a great reminder at the end of our testing course to make sure we are testing the right things in our software and that we are not creating too many, and useless tests that only hinder our efforts and not help us. I will certainly keep this article in mind when writing future tests to ensure I’m not wasting my time by creating the wrong kinds of tests or making sure every line is tested in a program.
Article link: https://dzone.com/articles/starting-automation-testing-from-scratch-here-is-w
Throughout this semester we have learned about how to create tests in a mostly “manual” way, today I want to explore an article that serves as an introduction and overall guide to automation testing. I especially wanted to learn about this topic since it has repeatedly come up in other articles I’ve read on this website.
Overall, I found the content of this article to be great and I think it thoroughly covers every aspect I can think of, and acts as a great beginner’s guide to this topic of automation testing. The author methodically covers everything on automation testing from the benefits of switching, to figuring out which areas of your testing should be automated.
Looking at the section of this article that lists the different areas automation testing can help is particularly interesting to me as most of the types of testing here I am unfamiliar with (and aren’t covered by our testing course) but would like to know more about. This includes areas such as regression testing, which I just learned about, and performance testing. From this article it seems that automation testing seems to help particularly with cross-browser testing. This made me think about how different web browsers are tested which is something I have only done by manually checking that the application functions properly by going through the program as a user. In retrospective it makes sense that some automated tool can make this much easier and I would like to see how this works more.
I think one of the most important points the author makes (and states many times) is “do not aim for a 100% automation”, which makes sense as the author explains how it is not necessarily feasible or beneficial to have all of your tests automated. Furthering this point, the other interesting part of this article is how the author explains that manually testing is better for certain aspects of software. After reading these reasons, I completely agree with the author that certain areas such as testing the actual user experience of a program makes more sense to test manually instead of automating. Another aspect I really like about this article that I like is that the author continues throughout the article to focus on the practicality of automating testing from a business standpoint and takes into account the amount of investment and return on investment that can be gained by automated testing.
This article has certainly made me more interested in testing automation and I would like to see how tools implement this, especially in areas the article says can really benefit from this such as regression or browser testing.
Article link: https://dzone.com/articles/why-do-programmers-fail-to-write-good-unit-tests
In this blog post I wanted to examine an article I found about unit testing. I think that since unit tests were one of the first types of testing we learned about and we have used unit tests as a foundation for many other testing methods this semester, reviewing this article serves as a great retrospective (and provides another viewpoint) on the importance of unit testing and defining criteria on writing “good” unit tests.
In the article, the author defines the significance of unit tests in creating software. They then go on to define some various qualities that make for a “good” unit test. I agree with the listed points, but I think this article could benefit by providing a few examples of good unit tests and maybe a few bad ones for comparison, especially since this is an article about programmers not correctly writing unit tests. I also think the article could better define what these “units” that are being tested are, since this term is used frequently throughout the article. Additionally, I think the article should better define what specifically is being tested in these “units” besides just saying “examine and test each unit of code separately”. Again, this is where some examples would greatly help illustrate the author’s point. The article then goes to list many benefits of writing unit tests. It ends with an interesting (and great) point of how just having unit tests isn’t necessarily beneficial (and can even be detrimental) if they are poorly written.
Overall, I think that after learning about and using unit tests a lot this semester, that this article can serve as a good introduction to the topic, and it certainly reaffirms what I have learned about unit testing, but I also think it requires some revisions to be more helpful in demonstrating the points it makes, as I find it to be somewhat vague in the fundamental parts of presenting the main concept of unit testing. I think that having a well written article about this topic is especially important as this type of testing is used as the basis for many other types of testing we have learned about. I also think that this article could include this point of how unit testing is used in the larger contexts of other types of testing such as ensuring code coverage to further prove its importance.
Article link: https://dzone.com/articles/what-is-regression-testing-and-why-is-it-important
Today I learned about regression testing from an excellent article on DZone and why it is an essential part of software testing. As the article explains, regression testing involves testing the whole software product to ensure that any changes to the code doesn’t break what was already working in the product or other parts of the software. The article then goes through a great example of how fixing a bug in one part of an example piece of software can unintentionally result in another (previously working) part of the system to stop working properly. The article demonstrates really well that this breakage can occur despite unit tests showing that the bug was fixed properly. This to me is an especially important point as it shows the value in using multiple methods of testing to ensure software is performing correctly. One criticism I do have of this article is that I wish they gave an example of how to implement regression (the article does include a link to a tool that performs regression testing) testing in an actual program (or in context of their previous example).
Although after reading this article, the concept of regression testing seems simple, I find it very important as both a software user and software developer. In my personal experience as a user I have seen everything from operating systems to video games release updates that caused features that worked fine previously to become buggy or stop working entirely. From the user perspective I know how frustrating this can be, so I am glad that I learned how to prevent this problem as a software developer. Regression testing is definitely something I now want to implement into my personal software projects. Now I need to look into the tools that can help do this.