After taking a quick look at JaCoCo in class I wanted to learn a bit more about it. This article is an introduction to using JaCoCo and gives some good examples.
The article explains that when you write tests there are some criteria to consider:
We want to make sure that the parts of the code that are best tested are the parts that are most likely to contain bugs.
We want to focus our tests on parts of the application that are critical, the parts where bugs are most likely to lead to a bad outcome for our customers.
We don’t want to write tests that repeatedly cover the same areas of the code while ignoring other parts of the code.
You can find which parts of the code are the most likely to have bugs by finding the most complex parts. A common way to do this is using cyclomatic complexity (check the article for the algorithm).
JaCoCo measures code coverage, can report on the complexity of each method, and can tell you how much complexity is untested. In the article a lot of the things we covered in class are repeated, but it helps to see it again to reinforce the concepts and also to reference for the future. While we spoke about it in class, a lot of the things that are said are not recorded anywhere.
The article also brings up the use of JaCoCo to measure complexity. After getting as much code coverage as possible you can refactor your code if the complexity score is too high. In the example they reduce a method’s complexity from 21 points to 9 points. That just goes to show how useful JaCoCo is. After reducing complexity and improving code coverage you can be confident your code is ready for a code review.
This week I wanted to learn a little more about code reviews. As first I thought, “Yeah code reviews just get someone to look at your code isn’t that common sense?”. After looking into it more I learned code reviews have a lot of benefits that you might not think of.
Code reviews share knowledge. Most people are going to be working as part of a team. With code reviews there is always more than one person that understands some portion of the project. This makes the team more flexible. With this shared knowledge also comes a better ability to estimate how much work some portion of the project is. When the reviewer gives feedback the are also exposed to the complexity that may underlie an issue. This gives multiple informed inputs to create more reliable estimates for the team.
Code reviews also give you a break from the monotony of a certain task. If you are spending a lot of time on a certain part of the project, doing a code review is like a breath of fresh air. It is liberating to work on a different area of the project. It can even feel fun, almost like a vacation.
Code reviews can also motivate developers to work harder. When you know one of your peers is going to take a look at your work you might take an extra effort to create something you find presentable. You would want your code to be clean and for all your tests to pass.
Code reviews are really more than just having someone else look at what you have done. They are an important part of any software development team and deserve to be formally incorporated into the development process.
This week I took a look at the pattern “Reading List”. According to this pattern, you should keep a list of books that you intend to read. By making a list of the books you have read and the are going to read, you give yourself an easy way to reflect on your own patterns of studying. As you read you will probably come across more books in the references or bibliography sections. You can add those books to your list as well. Your reading list should also be somewhere online and publicly available. Others may benefit from it or you may benefit from their suggestions.
Despite always being assigned at least one book for every CS course I have taken, I have never (at least until now) considered really using a book to learn about programming or computer science. It seems like a no-brainer to use the internet for anything computer related. Modern search engines allow you to ask extremely specific questions and get almost exactly what you are looking for. Maybe this is because as a student I always know what I need to learn.
As the author points out, it is hard to know where you need to go next or what you need to learn next. I am a student, so I always have a professor who provides a curriculum to follow and assignments to complete. I always know what I need to learn. This is all going to change now because I am graduating in a few weeks. I will have to take the initiative to set my own course of study if I want to improve as a programmer. Without any direction I should probably turn to books.
It is probably time I start reading more books about software development, especially if that is the field I am going to go into. Reading the “Apprenticeship Patterns” book has made me realize books do have a lot to offer aspiring programmers. They are a good way of forcing material in front of you. Because books are restricted by their physical form, authors have to put a lot of material in the book to make it worthwhile. You don’t have to figure out what to learn next; books are carefully curated sections of study, at least textbooks are. It’s about time I start my own reading list too, starting with all the books I neglected to read in the past few years.
This chapter’s opening quote was a very insightful one for me. It says: ” Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” The whole point of this chapter is that there are going to be times when you do not understand what is happening, what you need to do, or how to accomplish the task at hand. This is ok. Even if there are people depending on you to just know the right answer you will not always. You must ask questions and show that you are capable of learning how to do your job. That is how you grow as a craftsman.
“Expose your ignorance” is a pattern I have a lot to learn from. The opening quote talks about staying quiet when you do not know what is going on and that is something I am often guilty of. Just like the author says, I am afraid of looking incompetent. I often feel this way despite knowing I am not yet expected to be a competent programmer; if I were then I probably would not be in this class (I would consider some of my peers to be pretty competent though). As I student I am surrounded by professors who are literally being paid for me to expose my ignorance to, and they are happy to hear it. I am confident all the faculty in the CS department would love to hear more students ask questions and admit they do not have any idea what is going on. Most classes are silent though, especially in online courses. I am not sure if it is from a lack of interest in the course, the difficulties of online courses, or a fear of asking questions (it is probably a combination of the three.)
Moving forward I will really keep this pattern in mind, both as I finish this course and as I go out into the workforce. Not knowing everything does not mean you are not good enough. It simply means you are not good enough yet. Asking questions and actively working to improve shows that you are willing to put in the effort to become better.
This week I wanted to look at integration testing. Most projects have multiple components coded by different programmers. The purpose of integration testing is to expose any defects in the way these components interact with each other. It is sometimes called ‘I & T’ (Integration and Testing), ‘String Testing’, or ‘Thread Testing’.
Integration testing is the next level of testing after unit testing. While each individual component of the software is unit tested, there may still be defects. These may be because:
A module written by one programmer may have different logic and understanding of requirements from another causing their two components to work together improperly.
New requirements may be added by the customer that need to be tested.
The software may not be interacting with the database correctly.
There are multiple approaches to integration testing. Big bang testing is integrating all the components at once and testing as a unit. This works well for small systems, but it may be hard to isolate issues. Incremental testing starts with only a few modules ad gradually adds more after testing for proper function. This can be done bottom-up by testing lower-level modules first, or it can be done top-down with higher level modules first. There is also the sandwich method which tests higher level and lower level simultaneously and then combines the two.
While we have not yet taken a look at integration testing in class, I wanted to have a rough idea of what it is at least. I am sure our POGIL activities will go more in depth and explore why integration testing is used as well as exactly how it is done.
The apprenticeship pattern I chose this week is “Kindred Spirits”. According to this pattern, you may find yourself in a workplace that does not encourage software craftsmanship. In the absence of a mentor, you should find like-minded people who are also looking to become software craftsmen. Unlike mentors who are people you aspire to be like, peers are people you can feel more comfortable with. You can exchange ideas without feeling pressured like you might with a mentor. It is important to remember though that you should not just follow the crowd. It is important to think for yourself.
As a computer science student, I have the good fortune of being surrounded by kindred spirits. Most of my peers are of a similar experience level to me. Because we are all in the same classes, we are all learning the same language and doing the same assignments. It gives me so many other people I can bounce ideas off.
The author also discussed the difference between mentors and kindred spirits, and I think that difference is really highlighted when you are a student. It is often intimidating to ask professors for help or ask for their opinion. Sometimes when a professor tells you something or gives you a suggestion, you feel like that is the only way you can do something. With other students you are not as afraid to ask questions, especially if you are friends with each other. You are also able to take advice from them without feeling like that is the only way a problem can be solved.
Under the “Action” section the author discusses finding communities to join based on the languages you know or the tools you use. This is another benefit of being a student. Groups like the computer science club offer an in-person community to be a member of. It might be a bit harder to find a group after graduating but it is still do-able – especially with social media. If you cannot find an in-person group to join there will always be a discord server to join. You could even organize your own group easily using social media like the author says to do.
This week I wanted to learn more about the types of software testing that are out there. In class we already learned about methods like black and white box testing. I wanted to see if there were more methods that we may not have covered.
This article describes 7 of the most common software testing methods. It is important to note that software testing and software development as a whole is always changing. As such there are many more than just seven software testing methods and there will definitely be new methods created in the future. These seven here are just some of the most common.
Black Box Testing
White Box Testing
Something I found interesting about this article is the relationship the author outlined between automated and regression testing. Automated testing is making your tests run automatically and regression testing is testing to verify the system still works as it did before some changes were made. Automated and regression testing go hand in hand because as software is incrementally changed you have to perform regression testing often. This is the real purpose behind automated testing – you can test repeatedly.
Another interesting method that was discussed is exploratory testing. The author refers to it as a “lazy” method of testing but also acknowledges its merits. Exploratory testing is essentially looking at a certain area of an application and exploring for any unexpected behavior. This testing method does not have any test cases. While this testing method does not really apply to the small applications that we work with in class, it may be useful in the capstone course. In that course we are creating a much larger web application with a front and backend so exploring may prove useful.
There are also many testing tools with different functions. Some tools have multiple functions and some have only one.
Test launchers are used to launch your tests in the browser or Node.js with user config. (Karma, Jasmine, Jest, TestCafe, Cypress, webdriverio)
Testing structure providers help you arrange your tests in a readable and scalable way. (Mocha, Jasmine, Jest, Cucumber, TestCafe, Cypress)
Assertion functions are used to check if a test returns what you expect it to return and if its’t it throws a clear exception. (Chai, Jasmine, Jest, Unexpected, TestCafe, Cypress)
Generate and display test progress and summary. (Mocha, Jasmine, Jest, Karma, TestCafe, Cypress)
Mocks, spies, and stubs to simulate tests scenarios, isolate the tested part of the software from other parts, and attach to processes to see they work as expected. (Sinon, Jasmine, enzyme, Jest, testdouble)
Generate and compare snapshots to make sure changes to data structures from previous test runs are intended by the user’s code changes. (Jest, Ava)
Generate code coverage reports of how much of your code is covered by tests. (Istanbul, Jest, Blanket)
Browser Controllers simulate user actions for Functional Tests. (Nightwatch, Nightmare, Phantom, Puppeteer, TestCafe, Cypress)
Visual Regression Tools are used to compare your site to its previous versions visually by using image comparison techniques. (Applitools, Percy, Wraith, WebdriverCSS)
This week I took a look at the pattern “Craft over Art”. According to this pattern, programming is a craft not an art. As software developers, we are being hired to build some piece of software to solve a customer’s problem. We should not be trying to indulge our own interests by creating something we think is beautiful. While our software can be beautiful, it must primarily be functional.
This pattern made me think about how easy it is to get drawn into the program you are writing, especially if it is a project you are passionate about. You can quickly get sucked in and start trying to put every bell and whistle you can in, especially with projects that include a visual aspect. As students it is especially important to not go overboard. While extra effort is appreciated by instructors, you cannot get over an A grade anyway. That time should be spent on other things.
An important point here is also that as software developers we are providing a service to customers. Because of this we cannot wait for inspiration to strike before we start working on a project. We should still do satisfactory work even if the project is not something, we are passionate about. This is a profession not a hobby.
Something that was not touched on here is often times the most beautiful solution in programming is also the most functional and the most efficient. Programming is a very function driven field. Unlike painting or sculpting where the greatest pieces can also be the most abstract, programming rewards the code that is the cleanest and the most functional. It is unlikely for a programmer to create something that is more beautiful than useful, especially in a professional setting. I could definitely see it happening though in a personal project or in a field like game development.
The most important part I took away from this pattern is the need for a minimal level of quality. I typically focus on getting the job done as fast as possible. I need to learn to maintain a certain internal standard. Quality takes time and I must work on taking the time to do it right. In the future customers will not be as forgiving or provide as precise instructions as professors. I have to be prepared to solve real problems for real people that do not have solutions already.
This week I chose to look at the “Concrete Skills” pattern. This pattern explains that you need concrete skills to be able to get a job and contribute to the team you are joining. Concrete skills mean discrete abilities you can demonstrate using specific technologies. Something like understanding and being able to apply a certain framework or being able to write docker compose files. Things beyond soft skills like being able to learn quickly and having a good attitude. Creating a toy project can help show your concrete skills to employers and comparing your CV to the CVs of people whose skills you respect can help you take stock of where your own abilities stand.
I found this pattern interesting because it is a very helpful thing to think about when writing a resume or CV. Especially in a technical field like software development, you need to have very specific skills to be able to do the job you are hired for. Thinking about what concrete skills you have and making those specifics clear can really help you when looking for a job and it is definitely something I will be thinking about as I enter the workforce.
I also found it interesting when the author wrote about “buzzword bingo”. If you do a quick search for software development jobs, you do see a lot of these buzzwords and that can sometimes be really intimidating. Having ultra-high standards for software developers in kind of a meme now too (10+ years of experience in Swift required!!!). Making a list of these concrete skills helps make that a little less intimidating as you realize how capable you really are. That or it can help you see how far you need to go. Taking stock of your abilities is a good thing.
I know I am lacking a bit in the concrete skill area. A lot of the work we are doing with the project this semester will help fix that deficiency. We are working with so many new tools and I feel like I am learning more about software development than ever before. Putting myself in the uncomfortable position of creating something complex using brand new languages and technologies is pushing me towards becoming a better programmer.