The Mindset of Developers: Code Libraries vs. Frameworks [Part 1]

I decided to write this series of articles about the Mindset of Developers due to recurring questions among my students and other testers who have a hard time understanding the terminology, tools, technologies, libraries, and frameworks that exist out there in the “outer space” of product developers 🌌

In this series, I will discuss different concepts from the world of product development, what are the differences between code libraries and frameworks, what is more popular among developers, and how their product development choices affect us in the test automation world.

Table of Contents –The Mindset of Developers: The World of Mobile [Part 1]

1. You’re here → Chapter 1 – The Mindset of Developers: Code Libraries vs. Frameworks
2. Chapter 2 – The Mindset of Developers: React vs. Vue
3. Chapter 3 – The Mindset of Developers: The World of Mobile

You must have heard in the company corridors or in cafeteria conversations all sorts of buzzwords coming out of the developer’s mouths, such as: Angular, chitchatting about Node JS, and joking at the expense of those who fail to implement Redux… Well, us testers have our “curses” too (did anyone say STD here? 😄), and they have theirs. So let’s get to know these concepts a little bit further and understand what they really mean.

In this post, the first in our series (more coming up soon – stay tuned 👀), I want to start from the basics and answer a question that many people mistakenly think is the same: What are Code Libraries & What are Frameworks? And what are the differences between them?

Code Libraries

A code library is a collection of code lines that are designed to solve recurring problems. There are quite a few code libraries in the development world designed to solve many kinds of problems in various fields, for example, libraries for data science, libraries for complex mathematical problems, libraries for machine learning and libraries for automatic actions (did anyone say Selenium?)

Why do we even need it?

These product developers from a certain company, let’s call it Company A, work on the products and develop them from scratch. While working, they face quite a few problems and challenges that they eventually solve on their own. At the same time, developers from Company B also face challenges that are (not surprisingly) very similar to the same challenges encountered by developers of company A. And the same happens with developers in company C, D, etc… We have here a collection of the same problems that arise within different companies in software development. These companies can be VERY different in their products, in their business, their clientele, programming languages, etc… but still, the problems and challenges will be similar.

Which common problems can exist for everyone?

Here are a few examples:

• System connection authentication, permissions, information security
• Connectivity to database connection
• Writing analysis systems and fault reporting
• HTTP/S requests
• And much more…

You can all agree with me that these challenges can exist within an R&D team in a company like Wix, and at the same time for developers who wrote financial management systems in insurance companies for example. But in both cases, the same developers can get help from other developers in the world who have decided to write an Open Source project that solves the challenges they are facing (or at least one of them).

In general, this is the model behind code libraries – software projects designed to help other developers around the world solve shared problems (which reoccur in many other development teams) and help them focus on the development challenges of the specific domain they are working on. The code libraries expose an API (the same collection of methods that allows them to use other people’s solutions) with which they can reuse over and over again.

Let’s take an example from the real world. Suppose you’re a carpenter, and you’re interested in building a bed frame 🛌🔨: you can buy boards from the store, measure their length with your fingers, break them and somehow think of a solution to connect them. Or alternatively, you can bring a toolbox that includes: saw, hammer, drill, nails, screws, meter and so on… With this toolbox you can easily measure, mark & cut with great precision, and connect with screws and nails the boards for building the bed. Not only that, but with the same set of tools you can also build something else, such as a chair, table, or kitchen cabinets.

In our automation world, there is a wide range of code libraries, the most familiar and most popular is Selenium, whose libraries have been developed in a variety of programming languages, also called: “Bindings”. Note that Selenium is the code library, the automation tools are the drivers, such as: ChromeDriver, GeckoDriver, etc., and the protocol is called: WebDriver. Thus, if we will use a driving analogy, then:

• 🗾 Selenium is the driving directions from the point of departure to the destination, and these instructions can be written in different languages.
• ⚡ The ChromeDriver is the engine, accelerator and decelerator of the vehicle. This engine of the ChromDriver for example can only fit a “car” of the Chrome type.
• 🚗🚘🚙 The browser is the vehicle itself. As mentioned we have a variety of vehicles, such as Chrome, Firefox, Edge, etc., for each of its engine cars (GeckoDriver, EdgeDriver, ChromeDriver and more…).
• 🌄 WebDriver is the road we will travel to reach our destination.

Frameworks

Frameworks also give us reusable code capabilities and expose APIs, but the difference is that as opposed to code libraries, frameworks will also give us some kind of a skeleton or structures for writing software. This concept brings solutions to questions such as:

1. How should we build our product?
2. How can we reboot our product?
3. How can we integrate our product into other products?

To clarify, let’s go back to the same example of the carpenter who builds with his toolbox (code libraries) a frame for a wooden bed. Let’s say that this carpenter does not work alone, there are many more carpenters who build frames of wooden beds and they all go through more or less the same steps, for example – they all start with measurements using a meter, move on to cut the boards with the saw, connect the boards with the hammer and nails etc… So we have here a set of tools as we’ve mentioned before, and we also have a work method, some sort of list of the work steps, just like when we purchase a dresser from IKEA. In other words, we see here work patterns.

Therefore, the work can be optimized so that the same carpenters can now set up a factory with several machines (cutting, connecting, measuring…), even located at a geographical distance from each other, having a production line between them so that now the bed frames are built by machines that replace the carpenter’s day to day job. They can now simply control the machines to build, for example, various types of bed frames, but still the work itself is performed by the machines. This, my friends, is a wonderful example of what a Framework is.

Is it possible to take these machines and build a wooden boat for example? 🤷‍♂️ Well, not exactly. In order to build a wooden boat, we need to set up another factory, or in other words use a different framework.

In our test automation world, the same as with the code libraries, there are also quite a few frameworks out there, and TestProject is an excellent example of a framework. It is a package that contains Selenium code libraries (just like a factory has machines that are able to cut and measure), and it provides a more complete solution, such as the ability to run tests in parallel, receive test reports, define hierarchies of tests (Step / Test / Job / Project) and more … Whereas Selenium on its own does not provide all of this out of the box, but rather would require 3rd party tools.