TestFort published a blog (https://testfort.com/blog/difference-between-black-box-white-box-and-grey-box-testing#:~:text=While%20black%2Dbox%20testers%20make,in%20a%20non%2Dintrusive%20manner.) that does a great job breaking down each black-box, gray-box, and white/clear-box testing. By understanding each one individually, you can clearly see the differences between them. The blog also provides two other useful pieces of information for each of the software testing methods. Those being the most common design techniques and pros and cons.

Black Box Testing:

Testing is done by an independent team that has no knowledge of the code. The purpose of this testing method is to test the user interface’s functionality and usability. This testing method uses the users point of view to test the expected behaviors of the application.
The first example of black box testing that comes to mind is video-game testing. Testers are often given a demo of a game to play and give feedback on. These testers have no knowledge of the game’s code, however by playing the game they are testing for bugs and evaluating the user interface.

White/Clear Box Testing:

Testing is done by developers that have a great understanding of the application’s internal structure. This testing method’s purpose is to test and analyze that internal structure and its logic using the developers point of view. Developers commonly use tools to help analyze and debug code.
As I am only beginning my journey into developing tests I don’t have much experience with using debugging tools outside of ones provided inside some video games. However, when developing my own code I would commonly add print statements to verify variable values in the middle of the code. This would typically help me catch when values were being assigned incorrectly, scope issues, or simple off-by-one errors.

Gray Box Testing:

Testing can be done by developers, testers, and users with a similar testing approach as black box testing. Test cases are designed by an engineer that has decent knowledge of the internal structures. These test cases provide the testers with a glimpse into the software’s architecture without direct access to the source code. This form of testing aims to find defects and vulnerabilities in the structure of the code while combining the advantages of both black and white box testing.
This testing method is the one I have the least experience in, and is therefore the hardest for me to fully understand. My current understanding from this blog is relating it to when I would test software in the military. For obvious reasons, source code was hidden, however the functionality of each feature was documented so that testers could have a clear understanding of what the software was doing.

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

Summary:

This section really emphasizes the importance a mentor can have on someone’s apprenticeship. Guidance from someone who has already experienced the same or similar issues that you are going through is invaluable. On top of that, it establishes what realistic expectations one should have for a mentor. With computer science being such a vast field that is only getting larger, it’s unrealistic to expect one person to know everything about every topic. The last major point the section covers is that the flow of knowledge does not stop at you. An apprentice must be willing and able to pass on knowledge to other apprentices. 

Reflection:

Thinking back to my most impactful teachers and professors, it’s clear to see that their impact comes from their ability to mentor their students.  Having those impactful mentors throughout my education is what inspired me to seek a career in computer science. The best example I can come up with to relate the impact a mentor can have on an apprentice is this: Imagine trying to solve a hidden picture puzzle or “Where’s Waldo” and you can’t seem to figure it out. Having a mentor is like having a magnifying glass to help narrow down where you should be looking. This sense of direction is great to focus your efforts into researching helpful information. Considering how large the computer science field has grown.

When it comes to choosing a mentor in the computer science field, it is important to realize how large the field is. I have said it three times now, and I still don’t think that is enough to emphasize it. It is best to try and find a mentor that specializes in the field you want to learn about. Although, from my experiences, a mentor that does not specialize in the same field as you is still worth having. A mentor that specializes in any field can still give you tips on how they got to where they are. With the same mentality of teaching a person to fish over giving them a fish, learning how to learn is better than being taught something directly. With information so readily at our fingertips, the ability to research and find solutions is crucial in our world and especially the computer science field.

Bringing everything full circle is the idea that what separates an apprentice from a journeyman is the responsibility to help teach and mentor other apprentices. It makes sense that as I continue down the long path that there will be others behind me. I, personally, have always loved the spark that my mentors have ignited in me and it would be great to be able to pass that sling to others in the future.

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

As the title of this section suggests, it is solely focused on creating a reading list. On the surface, this section has to be the most straightforward in the book, and yet the one I practice/experience the least. With the ever-growing importance of broadening my learning through reading, I wanted to focus on this section as it feels like the obvious place to start.

Section Summary:

The idea of creating a reading list seems simple, yet so open-ended that it may also feel impossible. The section focuses on ways you can expand your reading list without feeling so overwhelmed with the endless knowledge that is available. When it comes to learning what books are important and useful enough to add to your list, it makes sense to ask mentors. Other online sources can offer reading lists from other people which may give a good insight of which books should be added to your list. The third way of finding useful sources was to pay attention to which sources are commonly referenced and cited in other readings. Seeing the same book cited multiple times can be a great indicator that it is an important book to add to your list. 

Reflection:

Having a list of which books to read next is a great way to stay organized however, having a reading list will also keep track of what books you have read. One of the points the reading made was that this list is also a reflection of your past reading habits. My list right now would reflect awful reading habits, and I must change that. When I first started to read through the patterns at the start of the semester I saw the entire chapter dedicated to reading and how important it was to broaden my education and craft with the use of reading. Starting a reading list from scratch felt like it was going to be an impossible task, with zero clue where to start or what books would be worth my time. With simple solutions provided by the reading, such as looking for likeminded lists from other people, asking mentors, and paying attention to the cited sources, I now feel way more comfortable with being able to develop my reading list.

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

The blog written by Krishna Teja Dinavahi, “Unit Testing – Is it Really Helpful?” (https://engineering.zoominfo.com/unit-testing-is-it-really-helpful) does a great job explaining the importance of writing unit testable code. What is also mentioned is how unit testing and integration testing are two different forms of testing that are both equally important. I specifically enjoyed this blog because of the great examples of code that was not unit testable along with the steps taken to refactor the code. 

What is Unit Testing and How is it Helpful?

As it’s mentioned in the blog, looking up unit testing online will give you the textbook definition, “Unit tests help you test individual parts of your application in isolation.” This is the same thing that was described to me in class, but I had the same general reaction to unit testing as Dinavahi describes. Unit testing can sometimes feel tedious and redundant. However, the real importance of unit testing is clear when you explore code that is not unit testable. Unit testing can not be done on code that is written poorly. This was the biggest eye opener for me as I read this blog, especially with the great examples provided. Notably, the one where having the external dependencies in its own function allows for easy bug fixing if anything was to change in the eternal API.

What Makes Code Unit Testable?

As I recently began refactoring old code with some of the new techniques and agile methods, I noticed the largest hurdle for me is being able to create “pure functions.” These are functions that are limited to doing one task and are very clear what that task is. From my experiences, having pure functions and good naming conventions are the two most important aspects to readable and scalable code. Approaching the code with unit testing in mind, the should automatically be written in a way that you will create pure functions. 

Conclusion

As someone who strives to write clean, readable code, I feel like I share the motivation Dinavahi expresses in the blog when it comes to learning unit testing. Each time I have refactored my code, I have always felt like it was just not finished. However, using unit testing I will be able to identify which parts of my code are not written properly and need to be refactored again. This time, with the knowledge of the steps I can take to get to unit testable code. 

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

As my journey to becoming a full stack developer continues, I have begun to encounter the need for front-end testing. When finding an article, I realized that I did not have very much knowledge on what front-end testing entailed or how to implement it into my coding. I found the blog “Front End Testing: A Comprehensive Overview” by Kiruthika Devaraj (https://testsigma.com/blog/front-end-testing/) on my search for information on this topic.

The blog starts off by explaining that front-end testing is focused on the user’s experience. While past experiences have taught me that back-end testing specifically tests the functionality of the code, front-end, also known as the user-facing end of a website, testing has a higher focus on the user’s interactions. The author also delves into eight different types of front-end testing and the elements that make up these different types:

• Unit Testing is the analysis and testing of the individual components to ensure they each work as intended. 
• Acceptance Testing involves testing to ensure permissions, such as account accesses, are working properly. 
• Visual Regression Testing tests for visual changes in the front-end by comparing a reference picture to a baseline image. This can typically create brittle tests that can fail due to the slightest changes in an element’s location on a page.
• Performance Testing measures an applications stability and responsiveness under different levels of simulated stress and traffic.
• Accessibility Testing ensures that individuals with visual impairments or other additional needs can still use and access the application to the fullest of their capabilities.
• End-to-End (E2E) Testing involves testing the application from start to finish while testing all components and systems for how they work together.
• Integration Testing is when each individual module is tested to ensure it has been implemented correctly.
• Cross-Browser Testing tests that the application works correctly across multiple browsers and confirms compatibility.

Devarj also provides tips for better front-end testing, the first tip is to always use a testing framework. These frameworks, also called front-end tools, are what actually run the tests. Although countless front-end tools exist, the blog provides information to 3 popular options; Testsigma, Selenium, and Ranorex. Testsigma and Selenium are both open-source front-end testing frameworks that may be worth investigating further, while Ranorexis a commercial framework that may be more than what I am currently looking for. 

Front-End Testing Moving Forward

As I move to implement automated front-end testing into my projects, it is important to remember that the front-end testing is focused on ensuring the project is user-friendly, responsive, and visually appealing by testing the layout, design, and functionality across multiple browsers. Doing so will provide users with the best possible experience.

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

Summary: 

The white belt pattern focuses on the idea that new situations should be approached with all previous knowledge set aside. The white belt signifies an entry level of knowledge and understanding of a subject, and is only achievable if all preconceptions and past experiences are removed during the learning process. This mental clean slate prevents old habits or patterns from getting in the way of exploring new possibilities when it comes to solving problems.

Reflection:

The more I reflect on this pattern the more I agree with it. However, my opinion felt like it went from agreeing to disagreeing back to agreeing. When in reality, it went from agreeing with some parts, and disagreeing with parts I didn’t fully understand. To eventually gaining an understanding of the pattern that I fully agree with.

Originally agreeing with the overall idea that you should have the mentality of a white belt when learning something new, I disagreed with the notion that all previous knowledge was bad. I, as do many others, learn by being able to take previous knowledge and experiences and relating them to the new situations. This however is the trap that this pattern is actually trying to avoid. The interesting part in this section that made me realize my mistake in my in initial interpretation was the “problem of ‘writing Fortran in any language.’” Not knowing what FORTRAN was, I researched it and found out that I was in fact making this same mistake. Learning a new language doesn’t mean just being able to recreate a simple program. It involves learning all the small nuances and limitations each language has. The only way to explore those is to approach each situation independently and with a clean slate.

My first language was java, and when it comes to learning a new language it is helpful for me to be able to relate things in the new language to elements in java. This turns out to be a trap if you are only looking for 1 to 1 relationships, or you let your old knowledge prevent you from learning something specific to the new language. The more I think back to all my older projects that involved learning in a language that was not java, all I actually learned was the syntax of how to rewrite my code in another language. My understanding of the language or coding in general did not get deeper. Having my previous knowledge acted more as blinders than guidelines, showing me the one way I already knew, but preventing me from seeing other possibilities I didn’t know even existed.

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