• Week 11 Blog

    This week’s blog will cover the main purpose of Object Oriented Testing and its usefulness. You most likely have heard the term “Object Oriented Programming”, which refers to a style of programming that utilizes classes, abstract classes, inheritance, polymorphism, concurrency, and more as a way of organizing code. These tools can be useful when dealing with multiple lines of code because it can be broken down into multiple files creating a more organized and readable product. Having a file with thousands of lines of code is a developers nightmare. Object Oriented Testing aims to test these systems and ensure they are behaving as expected. It is possible to have too much inheritance in a program, making it difficult to find where a piece of code is located, slowing down development. Unlike other test methods that primarily test function behavior, Object Oriented Testing analyzes the behavior of the entire class and its interactions with other files.

    There are multiple techniques to Object Oriented Testing: Unit Testing, Integration Testing, Inheritance Testing, Polymorphism Testing, and Encapsulation Testing just to name a few. Unit testing refers to testing of individual components of the class before testing the interactions it has with other classes. Initially testing the classes functions will prevent scenarios where you can’t locate the bug in the program because there are too many inherited classes. An example is testing each function and ensuring the behavior. Integration testing refers to testing objects of different classes and ensuring they behave properly with all the components. Inheritance testing aims to test the relationship between parent and child classes. This technique of testing also tests overridden functions are properly implemented and are actually overriding the function. Polymorphism testing aims to verify that objects of different types can be used interchangeably. This type of testing ensures the behavior across all types of objects. Encapsulation testing tests access control and ensures the data being accessed is allowed to be accessed by the user.

    The main benefits of running these tests is to detect defects early on rather than later in the development process. For this reason, it’s recommended to run tests throughout development. Object Oriented Testing ensures our project is modular, making it easier to maintain. In addition, it becomes easier to implement new features and classes without impacting existing code. Due to the never-ending demands of modern applications and the ever-evolving tech industry, the scalability of a program is crucial.

    Blogs chosen: https://medium.com/@hamzakhan522001/object-oriented-testing-1f9619da40d0
    and https://www.h2kinfosys.com/blog/object-oriented-testing/

  • Week 11 Blog

    This week’s topic I decided to choose a blog post about the writing of clean code to correlate with what we’ve been learning in class. The blog post, published by Jacob On Software, details how the writer has been reading Clean Code by Robert Martin. This handbook identifies the significance of writing clean code, as well as, how to properly write readable and professional code. Jacob On Software takes a unique and effective approach to teach readers; refactoring one of his old projects. Jacob states in his blog post that during this project, he was forced to learn how to create a full stack web application in just three weeks, resulting in him rushing and writing not so clean code. The blog post highlights that other contributors working on his project will have strenuous time trying to decipher his messy code, hindering the development process and evolution of the software.

    Looking at an image of the his code, we can see that the name of his functions are descriptive of what they accomplish, however the functions themselves have too many lines of code, which is a crucial aspect detailed in the Clean Code book. Having functions that are thousands of lines long makes it a nightmare to understand what the function is doing. Clean Code emphasizes that functions should be small and straight to the point. Jacob fixes his code by splitting up the function into smaller functions. Additionally, Martin’s Clean Code stresses that a function should do one thing. Previously, Jacob’s function was performing multiple operations like holding data and updating it. These operations were split up into their own functions, allowing others to instantly understand the purpose of these functions.

    Further into the blog, Jacob talks about the formatting of his code. The more lines a file has, the harder it is to understand. Users only have a limited amount code that will fit on their screen at once. If the developer has to constantly scroll up and down through hundreds of lines just to understand your code, you are not writing clean code. The same can be said horizontally, lines in your code should not be extending off to the right of the screen.

    I chose this topic because after looking at the examples of bad code and good code in class, I admit that most of my code that I’ve written in other classes would be considered bad code. Non-descriptive variable/function names and multiple operations in functions have definitely been a weakness in my code. It’s crucial to write clean code as software developer working in a team so other team members can easily understand your code. I plan to use this information as a guideline on how to write more descriptive and readable code in the future.

    Blog Post: https://medium.com/codex/reading-clean-code-week-2-643641e4dc28

Design a site like this with WordPress.com
Get started