Testing unfamiliar code can be a daunting task, especially if the code is complex, poorly documented, or written by someone else. However, testing is essential to ensure the quality, functionality, and reliability of the code. In this article, you will learn some practical tips and tools to help you test unfamiliar code effectively and efficiently.
Before you dive into the code, you need to have a clear idea of what the code is supposed to do and what are the expected inputs and outputs. This will help you design appropriate test cases and criteria to evaluate the code's performance. You can use the code's documentation, comments, or specifications to get this information. If the code lacks documentation, you can try to contact the original author or use tools like Doxygen or Javadoc to generate documentation from the code.
Your best place to start exploring is the various "entry" points. Is it a main() function? The receiving end of an API call? Begin from there and map out the flow. Follow a path that seems important. Find it by using the following heuristics: - Most probable execution: A function called from 10 different places, it's probably more important than a function called from only one place. - Naming indicates importance: A serveCustomers function in a ShopManager class, is likely significant. Then go down the rabbit hole until you believe you have a grasp of the relevant business logic and avoid wandering off to unrelated code. Last but not least, the more domain knowledge you possess, the easier understanding unfamiliar code will be.
Complex systems often contain simple parts. Look for a class with easy-to-understand attributes like a name or an id. Find a function that looks kind of generic and takes basic inputs. Find where these components are implemented, and build your knowledge from there. Leave comments along the way to make it more clear for yourself and the next person. Also, be patient with yourself! It can feel overwhelming to learn new systems. It takes time.
When it comes to testing unfamiliar code, one of the most common scenarios is taking ownership of it. Let's examine this scenario from this perspective. Other possible scopes include, but are not limited to, reverse engineering open-source or decompiled code, debugging the code for peer teams, or simply learning. In all these cases, to some extent, the concept of owning the code comes into play, either in thought or in practice. The process of evaluating code is inherently iterative. Throughout this process, you'll encounter and address various steps and stages, often in a different order. By mastering these steps, you can develop the most effective approach to taking ownership of the codebase.
Try to identify the business use case the code is trying to solve. Compare the code with the requirements or specifications of the project, if available. See if the code meets the expectations of the requirements.
Look for Swagger Docs if possible - sometimes these are well documented and give hints about inputs and outputs. Sometimes code commits might have JIRA tickets attached that could give background information on features implemented/original requirements.
Next, you need to get familiar with the code's structure and style. This will help you understand how the code is organized, how different components interact, and what are the coding conventions and standards followed. You can use tools like Code Climate or SonarQube to analyze the code's quality, complexity, and maintainability. You can also use tools like Prettier or ESLint to format and lint the code according to your preferences.
The larger picture is essential. Many tools generate different views of software. My personal favorite is Doxygen and Graphviz. While they are rudimentary feature-wise, they are easy to set up and quickly provide a high-level overview of the code. However, there's a new kid on the block: LLM (Large Language Model) based tools such as ChatGPT and GitHub Copilot. While they are still in their infancy, they can be surprisingly insightful in software comprehension. For example, they are relatively accurate in producing call graphs or elaborating on dependencies and associations between different parts of code. Give them a try. You will be pleasantly surprised, but always verify the output to avoid AI "hallucinations".
Absolutely, reviewing the code structure and style is crucial when trying to understand unfamiliar code. It provides valuable insights into how the code is organized, the naming conventions used, and the overall design patterns employed. by checking the version control history to understand the evolution of the code and any significant changes made over time is also helpful
Someone will thank you in the future if your coding style is readable, well-formatted, contains comments, and variables are clearly named.
Once you've wrapped your head around what the code's supposed to do, it's time to get cozy with its structure and style. This step's all about figuring out how everything's laid out, how the different parts talk to each other, and what kinda coding rules they're following. To make life easier, there are some slick tools in your toolkit. Stuff like Code Climate or SonarQube can help you suss out the code's quality, complexity, and how easy it is to maintain. And if you're picky about how your code looks and behaves, you've got pals like Prettier or ESLint to tidy things up according to your taste. It's all about getting that code in tip-top shape.
The code structure can be very difficult to understand. You need to dive into the developers' minds to understand exactly what they want. If you think this is important, in most cases, you are targeting a specific area or feature and ignoring most parts that are not important to your goal.
The best way to test unfamiliar code is to run it and observe its behavior. You can use tools like Postman or Insomnia to test the code's endpoints, APIs, or web services. You can also use tools like Chrome DevTools or Firefox Developer Tools to debug the code's front-end, inspect the DOM, and monitor the network activity. You can also use tools like logging, print statements, or breakpoints to trace the code's execution and output.
Use an iterative approach and adopt either a white or black-box testing strategy. The goal in both cases is to understand the "side effects" of an action. If there's a Graphical User Interface, go for a white-box approach. Click around and see which methods get invoked. On the other hand, if you've got an API or a library, go for a black-box approach. Create a minimal client that sends requests or calls functions, then see what responses you get. In either case, if you need to dig deeper, you could use a debugger or add some logging. Remember to keep a log of your findings. It will help you keep track of your progress and avoid repeating the same steps.
One of the most effective ways to test unfamiliar code is to run it and observe its behavior. This will provides valuable insights into how the code functions in a real-world environment. Tools like Postman and Insomnia are particularly useful for this purpose. They allow developers to send different types of requests to endpoints, view responses, and validate data. Review any logs or output generated by the code. Logs can provide valuable information about the code's behavior and any issues encountered
Behavior may be observed to work correctly at first. though we should always check for any unexpected inputs and ensure that it is handled correctly. Whether this be through an exemption, intentional crash out, error report, logging, input cleansing, etc
So, when you're dealing with code that's as foreign as an alien language, here's the deal: you gotta roll up your sleeves and see how it behaves firsthand. You've got Postman or Insomnia in your toolkit. These bad boys are ace for testing out those endpoints, APIs, or web services. Want to dive into the frontend? Chrome DevTools or Firefox Developer Tools are your buddies. You can peek under the hood, play with the DOM, and keep tabs on what's happening in the network. If you're a fan of old-school detective work, you can sprinkle in some logging, print statements, or breakpoints. These will help you follow the code's every move and see what it's spitting out. So, get hands-on, my friend, and crack that code wide open!
You can attach a debugger. You can boot up a fancy IDE. You can even set breakpoints in every interesting part of the code you can find. However, the smartest programmer I've ever worked with preferred to just insert a few print statements and click run. Sometimes, the simplest option is the best one.
Another way to test unfamiliar code is to write automated tests and generate coverage reports. Automated tests can help you verify the code's functionality, performance, and security. You can use tools like Jest, Mocha, or Pytest to write unit, integration, or end-to-end tests for the code. You can also use tools like Istanbul, Coveralls, or Codecov to generate coverage reports that show how much of the code is covered by the tests.
The first thing I always look for in unfamiliar code is whether or not there is any kind of automated testing. That could be anything for unit-testing, to integration testing. Oftentimes, when there is adequate testing, this alone is sufficient documentation for understanding the behavior and purpose of different sections of code. If there is no built in automated testing, then I will look for someone familiar with this code and have them explain their thought process when using different functionalities of the framework. Of course, understanding the business logic can also make a massive difference in understanding the purpose and intent of various implementations, so make sure to look for any resources or qualified subject matter experts
Need to work with a codebase long-term? Write tests! They help you understand the code and offer peace of mind during refactoring. One of the quickest ways to author automated tests for large, unknown software is by verifying the logs or output. Pick a scenario, run the code, save the output, and then compare it to future runs. This approach is rather naive and won't cover all the edge cases. More sophisticated tests will need to be written. Additionally, you may encounter a lot of false negatives since a different output doesn't necessarily imply a bug. Nonetheless, it's a good starting point as it requires little understanding of the code and shall smooth out the learning curve.
We can also verify the application and DB logs in order to understand the application flow. by writing automated test, with the use of testing frameworks like Selenium, Junit, Jest will surely help in code refactoring and making the application more stable.
Now, if you ask me, tackling unfamiliar code is like exploring uncharted territory. But guess what? We've got some high-tech tools at our disposal to make this journey smoother.When it comes to writing these tests, you've got options like Jest, Mocha, or Pytest. They're like your trusty sidekicks, ready to help you write unit tests, integration tests, or even those all-encompassing end-to-end tests. But here's the kicker: you don't stop there. You also want to know how much ground your tests are covering. That's where tools like Istanbul, Coveralls, or Codecov step in. They crunch the numbers and give you coverage reports, showing exactly which parts of the code are put to the test.
From a Code Ownership perspective, an essential metric is the code coverage provided by automated tests. Automated tests play a significant role in code delivery and transition. They are particularly crucial when transferring a substantial codebase within a limited timeframe. Another relevant metric to consider is the number of ignored tests. These tests, although ignored and not removed from the codebase, serve as indicators of dynamic code ownership. Additionally, they can be instrumental in managing known Technical Debt. Providing well-documented reasons for ignoring tests is imperative in this context. Automated tests, with comprehensive coverage and managed ignored tests, facilitate code ownership and enhance reliability.
Finally, you can test unfamiliar code by refactoring and improving it. Refactoring can help you make the code more readable, reusable, and maintainable. You can use tools like VS Code or Sublime Text to refactor the code using features like rename, extract, or move. You can also use tools like Code Smell Detector or Refactoring Guru to identify and fix common code smells or anti-patterns.
Software is malleable, and if used, it will be changed. When inheriting a codebase, you have to own it and evolve it. It is your responsibility to make the code easier to work with by refactoring it. You may improve readability, decrease complexity, change the architecture, etc. You should identify what quality attribute is lacking and optimize for it. Many tools can help, and don't underestimate the power of LLM-based tools. During refactoring, you should avoid introducing issues. Here is where automated tests come in handy. They help you verify the code still works as expected after your changes. Alternatively, you need to manually verify the code's behavior, something tedious and error-prone.
Well, when it comes to cracking the code on something new, sometimes you've got to roll up your sleeves and make it your own. Here's the scoop: you can test and understand unfamiliar code by giving it a makeover, making it more user-friendly, and easier to maintain. That's where refactoring comes into play. Think of it as a code makeover – tidying up, so to speak. The goal? Make the code more legible, reusable, and just plain better. Tools like Code Smell Detector or Refactoring Guru can be your guiding light. They'll help you pinpoint those not-so-pretty bits in the code, like common code smells or anti-patterns.
Next step, especially if you or your team is supposed to take ownership of the codebase, you can start refactoring the code for better matching the purposes of this ownership. One necessary condition for safe refactoring is the automated tests described above. If the piece of code you're identified to be refactored is not covered with tests, or available test cases conditions or their code coverage are not sufficient, refactoring may imperceptibly change the behavior of the code and thus affect the intention of initial authors of the code. If you suspect this unpleasant case, you have to return to the previous step and accordingly improve tests quality first.
While I agree with the points made, I've seen very few organizations taking refactoring actions based on outcomes of test coverage. Most of the code segments are avoided like plague since regression is a big nightmare. As a result, we have illogical variable names, tightly coupled complex code untouched, lying all around the codebase. The very purpose of making the code developer friendly is defeated.
Testing unfamiliar code is not only a way to ensure its quality, but also a way to learn from it. You can use testing as an opportunity to improve your coding skills, expand your knowledge, and discover new techniques or best practices. You can also use testing as a way to communicate with other developers, share feedback, and collaborate on the code.
Writing unit tests for unknown code will unavoidably increase your understanding of it. You start thinking about the code's behavior and how to use it when authoring your test suite. It also helps you identify edge and corner cases. Furthermore, you spot the code's dependencies and interactions with other components, as you may need to mock or stub them. Code comprehension via tests also works the other way. Complex software is often easier to understand by reading the tests first. They will show you what the code does instead of diving into the deep. This is especially true for large codebases with many dependencies and interactions or software that requires a lot of domain knowledge.
Combining all the preceding steps provides a comprehensive approach to learning and taking ownership of the code. When dealing with unfamiliar code, especially in a new language or ecosystem, these steps are valuable for assessing alignment with established best practices and efficiency. During this process, you can determine whether the code adheres to claimed or discovered purposes and scopes. If you anticipate providing support for this code, you may identify requirements for modifications or extensions to better serve its intended objectives. In essence, each step in the code ownership journey offers a unique opportunity for learning and enhancing your coding skills while ensuring code quality and alignment with best practices.
Prepare a variety of test data, including valid and invalid inputs, to cover a wide range of scenarios. This includes typical use cases and exceptional cases.
Code should ideally be accompanied by tests. If you inherit a codebase that's lacking them, write them yourself. It will expedite your learning process and help avoid introducing bugs in the future. If the original author is available, request a walkthrough. It will give you an insight and understanding not just of the code, but also of the design decisions behind it. Often, you refactor for testability. In that case, make sure you don't introduce regressions. Project management will be reluctant about large refactoring initiatives due to low immediate ROI and high risk. Instead, gradually refactor an existing code base while introducing tests. It increases both your understanding of the code and confidence.
If you encounter code that is particularly complex or unclear, don't hesitate to reach out to the code's author or team members for clarification. They may be able to provide insights into the code's design and intent.
An important aspect of testing unfamiliar code is delving into its history. When you take ownership of a codebase in real-life, it's likely to be stored in a version control system. This presents a valuable opportunity to explore its historical journey. Personally, I often begin my code ownership journey with a thorough review of the source control where the codebase resides. The structure of branches and tags can unveil the story of how the code evolved over time. This historical context may shed light on unclear aspects in the code. Additionally, commit messages, notes in code review areas, such as pull requests give more idea on the coders' intentions and goals. These may refer to other valuable sources such as issue trackers.