Tomorrow, we are migrating our website to the [Showmax.Engineering](https://showmax.engineering) domain. We are changing hosting, administrative framework, and the overall look & feel. To make the website easy to manage for our back office and talent acquisition teams, we chose to build it on Wordpress.

Recently, we’ve focused on acquiring new talent, so we used this opportunity and wrote more about our teams, showcased blog posts about what they do, and listed all of our job openings more prominently.

For RSS subscribers, just change the link to: https://showmax.engineering/feed/ (the original link https://tech.showmax.com/feed.xml will be redirected to the new one).

Discover the remarkable evolution of Android TV development, as we share insights into how innovation, adaptability, and user-centric design transformed our app. Dive into a journey that redefines TV streaming.

Elevating Android TV Development: A Journey of Innovation and Transformation

As engineers, developing a video-streaming app that lets people enjoy movies anytime and anywhere means expanding your reach across multiple platforms. With a limited team, it's crucial to ensure consistent support for development, bug fixes, and features. Prioritizing the most widely used platforms makes logical sense. In this context, the African market takes center stage – it's mobile-first, with users watching content on the go, during commutes, and while traveling long distances.

Previously at Showmax, we faced the challenge of catering to diverse platforms with a single mobile team. This team was responsible for developing mobile apps for both Android and iOS, as well as covering Android TV and tvOS. This approach seemed reasonable due to shared programming languages and potential codebase integration. However, the TV experience, known as "leanback" due to users typically leaning back on a sofa while watching on a large TV screen, brought unique design and product considerations. And unfortunately, the platform’s UX was a bit left behind. 

When we set out to develop an Android TV app, we opted for a simple approach that adhered to industry standards. We built our application using the Android Leanback library.

This widely-used library is officially supported by Android, sparing developers from implementing all views, components, and intricate interactions (think of navigation in a 'touchless' environment). It offers solid system support out of the box.

Designing an app for the TV platform is cost-effective due to existing elements and limited design adjustments.

Due to technological advancements, the library has become somewhat dated, impacting the user experience and necessitating significant adjustments for TV app development.

As mentioned earlier, design and product decisions are constrained by the Leanback library's components and layouts.

One colleague, who is an Android TV owner and enthusiast, aptly pointed out the UX during a redesign demo: "Android TV users are simply used to [visually] suffering when using the apps."

The original Showmax Android TV application was constructed several years ago using components from the Leanback Library.

These challenges, combined with a heightened focus on mobile apps (given their prevalence in African markets) and a lack of dedicated design or product management for the Android TV platform, led us to approach the app as an MVP – a minimum viable product. While supporting new features, we prioritized basic functionality over specific or elaborate designs.

With a commitment to allocate 10 percent of our time to innovation and approximately 30 percent to address technical debt and engineering tasks, we aimed for a more balanced approach. This ensured we weren't solely focused on external demands and features from other teams. Thus, we capitalized on this time to enhance our Android TV app.

Our initial step was a common one – identifying pain points collectively. With developers, testers, and app users, we unearthed numerous minor issues ripe for fixing. These low-hanging fruit were prioritized based on technical complexity and potential impact on user experience. We utilized our technical allocation to incorporate these improvements into our plans. This phase primarily involved resolving UI issues and refining navigation between screens. We conducted A/B tests and drew insights from other platform tests and improvements. Additionally, we integrated sought-after features already implemented by other TV teams. Our focus was on tasks demanding minimal Product or Design involvement, requiring limited effort on our part and no backend changes.

The outcome was remarkably positive – we received favorable internal feedback and users' reviews and questionnaires echoed the improvements.

Following the swift fixes, we tackled more substantial challenges that demanded significant time investments across multiple teams. Since our team wasn't overflowing with resources, including Product and Design teams, we needed alignment with other priorities. At this juncture, before delving heavily into the existing app, we proposed a comprehensive platform overhaul. We faced two options: retain native platform support or port our existing JavaScript-based solution for smart TVs to the Android platform.

The smart TV solution was already in use on the web and various TV brands. Adding the native player, which we already possessed, made it the quickest and most cost-effective choice. Unfortunately, the performance of the ported JavaScript application was underwhelming on regular Android TV boxes, and our smart TV team lacked the bandwidth for performance optimization. The alternative was to proceed with the native approach. While promising a superior user experience and performance, this route required significant investment. Thanks to the positive outcomes from initial changes, available team capacity, and the considerable presence of Android TVs in the market, we obtained the green light for this revitalization effort.

To kick start the process, we brought in a dedicated designer fresh from another project within the company. Additionally, we allocated 30% of one of our Product Managers' time to assist with the project. As the team leader, I dedicated half of my time to this endeavor. Furthermore, we appointed a Lead Android TV engineer from our team to closely collaborate with the group, forming a well-rounded product trio.

In conclusion, our journey toward enhancing the Android TV app involved simplifying the technical approach, tackling challenges incrementally, and nurturing innovation within our team. The outcome was a more refined and user-friendly app that aligned with the unique demands of the Android TV platform.

In our pursuit of enhancing the Android TV app, we embarked on an in-depth research journey. Building upon our initial issue triage, we conducted numerous customer interviews and testing sessions, effectively creating an extensive Design sprint.  (The process of rethinking the solution and opportunity mapping was similar to what we have described in the blog post focusing on data driven design process). Through these efforts, we identified major pain points. However, we realized that many of these challenges couldn't be easily resolved within the confines of the existing Leanback library offered by Google. Addressing them would necessitate substantial investments in new development and a comprehensive app rewrite.

We started by a screen-by-screen analysis of the current solution with gathering feedback from all stakeholders to identify all opportunities.

Recognizing the need for analytical insights, we enlisted the aid of one of our Data Analysts. They assisted in the data crunching required to assess the current solution and support the tests and experiments we were eager to undertake. Armed with a solid justification for additional resources, we found ourselves in a position where innovation knew no bounds. Our platform transformed into a dynamic research lab.

Subsequently, Affinity mapping helped us identify the key ideas and assumptions to prioritize.

Taking a bold step, we bid farewell to the outdated Leanback library that had previously constrained us. This opened the door to entirely fresh designs, whether they involved individual elements or entire screens. Our approach now encompassed a spectrum of innovative solutions, often drawing from successful strategies on similar platforms. This approach led us to pioneer novel navigation methods – some of which were eventually embraced by other TV platforms. Additionally, we refined content promotion techniques and introduced a range of feature enhancements. During this phase, we also embraced a new Design system, a tool that greatly expedited the platform revamp process. Interestingly, while our Android team had hesitated to adopt the Design system for their mobile app due to its established functionality, they eagerly embraced it for the TV app, recognizing its potential as we built it from the ground up.

Finally, we prioritized the solutions based on technical feasibility and user impact using a simple prioritization matrix to determine what to address first.

As our journey progressed, it became evident that our esteemed platform demanded full-fledged attention. In response, we took significant steps to reinforce our efforts. We welcomed a dedicated Product Manager exclusively responsible for Android TV. Simultaneously, we selected a developer from our ranks and elevated them to the role of Android TV platform lead, overseeing all matters related to ATV. The addition of the new Product Manager necessitated a reevaluation of our team's capacity allocation. The outcome was a balanced distribution – one-third for mobile, one-third for TV, and one-third for our team's internal technical initiatives.

In closing, our commitment to research and innovation transformed our Android TV app from a mere platform into a dynamic laboratory of ideas. Through tenacity and adaptability, we ushered in a new era of design, functionality, and user experience, propelling our app to the forefront of modern TV streaming platforms.

The reworked application has a modern appearance, employing custom-built elements and layouts derived from our in-house design system.

Our journey to enhance the Android TV app underscored the value of adaptability and innovation in a rapidly evolving landscape. What started as a quest to improve user experience culminated in a transformative process that redefined our platform's capabilities. By challenging convention, embracing research, and fostering a culture of exploration, we unlocked new avenues for design and functionality. The lessons we learned along the way, the hurdles we overcame, and the innovations we championed have paved the path for a future where the Android TV experience continues to elevate and captivate our users. With a dedicated team, a fresh approach, and a willingness to push boundaries, we are excited to embark on this new chapter of Android TV development, armed with the knowledge that every challenge is an opportunity and every innovation propels us toward excellence. Together, we journey onward, crafting a dynamic TV streaming experience that resonates with viewers in every corner of Showmax’s market in Africa.

Earlier this year, Google introduced a new Leanback library based on Jetpack Compose. We were proud early adopters of this library and are pleased that we could contribute to shaping the future of Leanback development through our participation in Google’s Early Access Program. Without our prior internal efforts to rework the TV platform, this would not have been achievable. You can find more information in our recent blog post on Baseline Profiles for Android or explore our talks on the Android TV transformation and adoption of Jetpack Compose for Android TV.

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Discover Kotlin Multiplatform Mobile (KMP) in our latest blog post authored by David Aldorf (iOS) and Tomáš Král (Android). Explore the benefits, challenges, and performance considerations of this powerful framework for multi-platform app development. Uncover the potential of code sharing and seamless UI development with Compose Multiplatform. Whether you're an iOS or Android developer, KMP offers a game-changing approach to mobile app development. Dive in now!

Exploring Kotlin Multiplatform Mobile (KMP): A Comprehensive Overview by David Aldorf and Tomáš Král

Authorship Disclaimer: This blog post was co-authored by David Aldorf and Tomáš Král.

The realm of multi-platform development has received a remarkable addition with JetBrains' new framework known as Kotlin Multiplatform Mobile (KMM), which has evolved to be Kotlin Multiplatform (KMP) since September 2023. The primary objective of KMP is to facilitate code sharing across various platforms, effectively curbing development costs. In this article, we dive into KMP, its unique features, challenges faced during implementation, and its applicability to real-world projects.

So why did we opt for Kotlin Multiplatform? We were driven by the aspiration to maximize code sharing, and with Compose UI now available on iOS, we chose to embark on this path to achieve our goal. This decision promised not only efficient cross-platform development but also the potential to leverage the modern Compose framework seamlessly across iOS and other platforms.

Popular apps using Kotlin Multiplatform (KMP) in 2023

Kotlin Multiplatform (KMP) extends beyond Android to encompass platforms like iOS, web, and desktop. It unifies a shared codebase for internal API access across iOS, Android, web, and desktop, with a standout feature being its native compilation for each target platform. This is made possible by the Kotlin/Native compiler for iOS and desktop and the Kotlin/JVM compiler for Android. Notably, for iOS, the Kotlin/Native compiler translates Kotlin code into LLVM bytecode, seamlessly integrating with Swift runtime components and resulting in iOS app bundles.

The goal is to write to a shared module and especially to commonMain as much code as possible. This part is shared with all platforms. androidMain and iosMain in the shared module are used for platform-specific code. It is written in Kotlin but it can work with platform-specific APIs and libraries. This is pure magic, especially on the iOS side. androidApp and iosApp modules are standard Android/iOS applications using the shared module as a library.

This PoC was written from scratch and it makes sense to us to have just one shared module/library. But in real life, it is possible to make more of them. For example, one for the data layer, one for data storage, etc. Also, a database-shared module can be used the same way on all platforms regardless if it is Room on Android or Realm on iOS. These platform-specific things will be in the Android/iOS part of the shared module. Android and iOS applications will just call a simple facade API.

We use it just for Android and iOS but it can be used for Web and Desktop as well. JetBrains devs are going even further and their idea is to share the same Domain models and services between Backend and Frontend.

Our goal is clear: to create a prototype app that showcases a grid of movies and series. When users tap on an item, they'll see detailed info about it and be able to start watching. To achieve this, we'll download the assets and make sure users can play videos from their source URLs.

Before we start KMP development, we need to set up Environment and Project. Xcode, Android Studio, and the Kotlin Multiplatform Mobile plugin are essential. A helpful tool named Kdoctor aids in setting up and validating the development environment. CocoaPods are optional, even JetBrains says to avoid them if your project is not using CocoaPods dependencies. Because it is a more complicated setup.

Good information on how to start can be found here: 

https://kotlinlang.org/docs/multiplatform-mobile-getting-started.html

https://www.youtube.com/watch?v=CIZU_NNAZsA&list=PLlFc5cFwUnmxSiLW3xyStFSbEslmUSG3p

https://terrakok.github.io/kmp-web-wizard/

Android Studio has a wizard-driven setup, resulting in separate iOS and Android apps that share a common codebase. Although this setup appears unified and it is good for getting familiar with KMP,. Iin reality, Android app, iOS app, and KMP module/library (which is in our case called shared) will be  in separate repositories. 

You can check this wizard if you want some inspiration for the build.gradle setup. It especially helps with setting up gradle for specific platforms and dependencies.

It is awesome how simple it is to run an iOS app from Android Studio. The iOS one is created and configured the same way the Android one is. All devices from Xcode can be selected as an execution target.

Compose Multiplatform: Unifying UI Development

Jetpack Compose has transformed UI development, especially on Android, offering a seamless and robust solution. Compose Multiplatform takes this innovation a step further, extending its benefits without drawbacks. It empowers developers to craft captivating interfaces seamlessly on Android.

For iOS, Compose Multiplatform employs Skiko for a unique Canvas-style interpretation, breathing creativity into UI development. While it differs from the UIKit-based approach, it ensures UI interoperability via iOS widgets/UIKit and SwiftUI. By embedding native UI components in shared UIs through elements like UIKitView and ComposeUIViewController, platforms blend effortlessly.

Notably, Compose Multiplatform doesn't cover tvOS, but Kotlin Multiplatform (KMP) remains reliable here. This demonstrates KMP's flexibility in diverse contexts.

For an in-depth look, explore the Compose Multiplatform GitHub repository, a hub of collaborative innovation driving cross-platform UI development.

There are a lot of multiplatform libraries available these days, so you can easily avoid platform-specific implementation. Still, there is room for improvement. In our case, the library for the video player was missing. Even so, the number of KMP libraries is growing every day.

From an iOS developer's viewpoint, adopting KMP can entail a shift to a new IDE (Android Studio), potentially complicating the entry process. While syntax similarities might ease the transition, debugging in Xcode and adapting to Compose's alpha stage on iOS could present challenges. Business logic and networking layers are prime candidates for code sharing, whereas platform-specific concerns often linger.

Android developers have it way simpler. The only big differences between pure Android and KMP projects are build.gradle and project modules structure. Even Compose UI stays almost untouched.

To call a platform-specific API in the shared module, it is necessary to step out from commonMain to androidMain and/or iosMain. It is possible to do it simply by Interface or the new JetBrains construct expect/actual can be used. Expect/actual will force programmers to implement new features on all platforms. To use it, just annotate the desired value, variable, function, or class in commonMain by expecting the keyword to tell the compiler that the actual implementation will be in the platform-specific part of the shared module. Then annotate the real implementation with ‘actual’ in androidMain and iosMain.

In this case the Android app uses ExoPlayer. We used an Exoplayer with MediaSource and AndroidView to be able to use it in Compose.

Navigating the iOS landscape introduces some complexities, yet KMP comes to the rescue. We tap into iOS internal APIs like Foundation, UIKit, AVFoundation, and SwiftUI, and here, KMP lends a hand by allowing us to utilize these APIs through Kotlin. For instance, we opted for AVPlayer. The process is relatively straightforward: we initialize AVPlayer much like on iOS, with the only distinction being the encapsulation within a UIKitView.

In such cases, the Alpha version of Compose Multiplatform introduces a prototype for seamless UI interoperability. With UIKitView, you can easily integrate advanced platform-specific elements such as maps, web views, media players, and cameras into your shared user interface. Conversely, through ComposeUIViewController, you can smoothly incorporate Compose Multiplatform screens into your SwiftUI-based iOS applications, making the transition to Compose Multiplatform a gradual and convenient process. In this case, you can use Compose Multiplatform alongside your current UI layer. You can read more about it in this article: Compose Multiplatform for iOS Is in Alpha.

While KMP excels in facilitating multi-platform development, it's essential to note that iOS compile times might experience a slight increase during KMP app development within Xcode. Therefore, the run-time seems the same as a native app.

While KMP presents a seamless approach to multi-platform development, it does come with some challenges. Debugging on iOS involves separate debuggers for iosApp and shared components. Setting up Xcode Command line tools and integrating CocoaPods might get complicated. Finding help online (StackOverflow, etc.) can be tough since KMP is relatively new. Finding a solution may require going through public repositories.

Kotlin Multiplatform, now called Kotlin Multiplatform (KMP), offers a revolutionary way to build apps for multiple platforms. It lets you share code and easily connect to internal APIs, making development efficient and cost-effective. However, using it for full multiplatform UI development can be challenging, especially on iOS, where Compose Multiplatform is in its early stages, and tvOS is unsupported. KMP excels at sharing business logic, data layers, and domain models, making testing simpler. We recommend giving it a try and gradually integrating it into your project, starting small, and not needing a major code overhaul. You can begin with one feature or API calls and expand from there to share more code with your fellow developers. The key is that you don't have to rewrite everything at once to benefit from KMP.

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Explore how user clustering through k-means algorithm, graph algorithms, and content embedding models enhances content recommendations. Learn about the fusion of classic methods and modern technologies to understand user preferences better.

User Clustering for Improved Content Recommendations: A Fusion of Classic and Modern Techniques

Recently, our Content Discovery team, stationed at the intersection of our vast video content library and the users choosing what to watch on our streaming platform, embarked on an essential mission: clustering users based on their similar viewing behaviors to refine our video content recommendations. We explored various modern algorithms, but interestingly, it was the classic k-means algorithm that proved to be the most effective. Let's dive into our journey and see how we tackled the challenge of user clustering.

In the world of personalized experiences and custom offerings, our way of creating group-based content recommendations offers a really interesting option. While acknowledging its drawback, we must also recognize a notable advantage – this approach requires significantly fewer computational resources. And on top of that, it opens up a whole new space for diverse analyses and A/B testing within these newly defined user cohorts. Some things work better for certain groups of users, and we really wanted a good way to see that. And now, we have achieved it.

We kicked off with a straightforward approach: constructing a matrix where each user corresponds to a row and each movie or TV series is represented by a column. The matrix elements were binary, taking the value of 0 or 1 based on whether the user had viewed a particular title. With the groundwork laid, we proceeded to implement a clustering algorithm of our choosing and eagerly anticipated the outcomes. 

However, as we delved into the results, we discovered significant drawbacks inherent in this approach. Firstly, we realized that the distance between user vectors remained constant whether they both watched a particular title or neither did. Imagine a scenario where there are 10,000 titles available, and two users have each watched 5 titles. Among these, only 3 titles are common to both users. Strikingly, this results in a situation where they share 9,996 assets, whether watched or not, while the actual shared viewing experience comprises just 3 titles. Our intention was to give more weight to the positive data in order to emphasize shared content rather than the absence of it. Regrettably, our results didn't align with this desired emphasis.

Furthermore, another issue emerged: The similarity measure treated users who watched similar titles identically to users who had vastly different viewing preferences. For instance, consider Alice, who watched "Top Gun," and Bob, who saw "Top Gun: Maverick." But their dissimilarity is exactly the same as Xavier and Yasmine, who respectively viewed "Paw Patrol" and "Big Brother" – two very different titles. We realized we needed to address these challenges for a more effective user clustering solution.

To address these challenges head-on, we pivoted toward the realm of graph algorithms. We opted to represent our users as individual nodes within a graph, with edges signifying instances where two users shared a common content-viewing experience. These edges carried weights, indicating the number of titles shared in common – a vital shift that allowed us to focus on the positive data, accentuating the shared preferences rather than disparities. Additionally, this approach unveiled an intriguing aspect: when two users had similar viewing histories, it often meant numerous other users had also watched the same titles, leading to an abundance of shared neighbors within the graph. It seemed like the path forward.

However, it's important to note that this graph-based solution came with a significant memory overhead, unlike the initial matrix approach. In big O notation, the memory requirement was proportional to the square of the number of users, while the matrix approach was simply a product of the number of users and the number of titles (considering Showmax has several orders of magnitude more users than titles). To mitigate this, we explored various divide-and-conquer techniques, which indeed yielded meaningful results and stunning visualizations (as depicted in the figure below). 

Visualization of clustered users using a graph-tool library. Each user is represented by a node on the exterior circle and edges signify commonly watched titles.

Despite these successes, we encountered a roadblock: the graph-based approach consumed excessive CPU resources, leading us to make the decision to close this particular avenue of research. Still, we kept some of the charts as stunning and CDR-relevant office decorations.

After our experiment with graph algorithms yielded unsatisfactory results, we circled back to the original matrix approach and sought to refine the user vectors for a more accurate depiction of user preferences. Let me discuss some of the approaches we considered but ultimately did not implement for production.

One straightforward method involves the use of dimensionality reduction algorithms, such as PCA (Principal Component Analysis), t-SNE (t-Distributed Stochastic Neighbor Embedding), or UMAP (Uniform Manifold Approximation and Projection). The underlying concept here is that when two titles are watched by the same users, the corresponding columns in the matrix should exhibit a strong correlation, and the resulting lower-dimensional representation should have a composite column that captures the essence of both titles. In such cases, the specific title a user watches becomes less significant – the resulting vectors should be remarkably similar.

Another related technique is the use of autoencoders. These are neural networks with identical data on both the input and output layers, with a relatively compact hidden layer positioned in the middle. Essentially, the network attempts to squeeze as much information as possible through these artificially created bottlenecks. We're particularly interested in the vector at the narrowest point, which holds valuable compressed information. Autoencoders find extensive application in recommender systems due to the nature of the network, which aims to predict the content a user might watch based on their past viewing history, albeit with the distinction that the input is precisely what is being predicted.

However, we had another tool at our disposal – a content embedding model. This model allowed us to measure the similarity between two titles using cosine similarity. We integrated this into the refinement of our original matrix structure. When a user had watched a particular title, we assigned a value of 1 to that matrix position. When a title wasn't watched, we searched for the most similar content they had viewed and plugged the similarity score into our matrix. As a result, our matrix columns became strikingly correlated for similar titles. This transformation enabled us to choose a subset of reference titles, setting the stage for a relatively simple clustering algorithm, k-means, in our case.

This approach also had an interesting side benefit - it made the process more explainable. The user features were designed based on "how similar the content is to the title the user watched," and the k-means clustering provided cluster centers that held valuable insights. This allowed us to describe the clusters in terms of their similarities to the reference titles. For example, we could say that a cluster was most akin to titles of a certain genre while having little similarity to another genre. Alternatively, we could explore which groups of users resembled a specific set of titles the most. This unexpected advantage brought a layer of clarity and understanding to our clustering results, enhancing the overall value of our approach.

In conclusion, our journey through user clustering led us to explore graph algorithms and content embedding models, blending classic and modern techniques, and arriving at an innovative solution. We discovered that, when it comes to understanding preferences and improving group recommendations, the pursuit of explainability and efficiency is the most effective. Our adaptation of the k-means algorithm empowered us to create user cohorts that provided not just valuable analytical insights, but also a clear, interpretable perspective on the preferences of various user groups. Our approach demonstrates how the fusion of classic methods and modern technologies can progress the understanding of user behavior in the ever-evolving digital landscape.

Clustering Users for Better Content Recommendations

Learn how to systematically test all endpoints in Django using powerful testing tools like the Django test framework and pytest. Ensure a seamless user experience and robust security by identifying and fixing broken links and maintaining all endpoints. Dive into this step-by-step overview of the testing process.

Comprehensive Guide to Testing All Endpoints in Django

Testing is a crucial aspect of software development, particularly in web development. Even a single broken link or endpoint can result in a poor user experience or security vulnerabilities. Luckily, Django offers powerful testing tools, including the Django test framework, which can be enhanced with third-party packages like pytest to tackle these challenges.

When dealing with large, long-standing systems, it's common to have numerous endpoints. Many of these endpoints may be infrequently used but still necessary. Unfortunately, they can easily slip from our minds when implementing changes, leading to unforeseen impacts on users that go undetected.

In this developer blog post, we'll dive into an approach for testing all the endpoints of a Django server. We'll utilize the "show_urls" command from django-extensions and the "get" method of pytest's django_app_factory plugin. Together, these tools will enable us to systematically test each endpoint. Join us as we walk through the entire process, providing a detailed explanation of how it all works.

The show_urls command is a useful tool provided by django-extensions that offers a list of all endpoints in JSON format. Each entry returned has four fields: url, module, name, and decorators. By iterating over the returned list, we can test each endpoint with a GET request to identify broken links and ensure that all endpoints are functioning properly.

To implement this test, we can start by using Django's call_command method to run the show_urls command and get a list of all endpoints.

The first step after acquiring all endpoints is to sort them based on whether they are maintained or not. This can be achieved by checking the module field that contains “path” for the endpoint, because the first part of the path is the app name. 

Having the app name, we can now easily check if the app is maintained or not, and skip the ones that are not.

Next, let's focus on constructing the URL for our GET request. To ensure we have all the necessary data, we'll need to consider adding query parameters and keyword arguments to the URL field. In Django, we can achieve this using the url field and leverage the Django syntax.

For keyword arguments, there are many that are generated by django as a model. These models follow a pattern that we can easily use and replace for its intended value. But there are some that don’t follow this pattern which are mostly custom endpoints that need to be checked individually to add their value.

Unfortunately, there is no easy way to check query parameters as there is no denotation for them on the url, so they need to be checked individually by looking into the code, usually after a request fails.

In this step we need to create a high amount of pytest fixtures too as most of the values needed are model identifiers or are related to them.

Once we have built the URL and necessary data, we can perform the GET request using pytest's django_app_factory plugin's get() method. In this step, more fixtures may be required and there's also a possibility of internal errors occurring. I had some occurrences of implementation errors from old endpoints in production showing some good results from these tests already.

There is not much that can be done here other than waiting for a response and following to the next step or handling the errors that happen from time to time.

Finally, we need to check the status code returned by the GET request. If the code is outside the 2xx range and is not 405, indicating that the endpoint does not allow GET requests, the test will fail unless this endpoint is explicitly listed as expecting another code. The request follows redirects, so we should not receive any 3xx code either.

In conclusion, thoroughly testing all the endpoints of a Django server is a crucial step in guaranteeing the smooth functioning of a web application and delivering a positive user experience. Fortunately, with the powerful Django test framework and the aid of valuable third-party packages such as django-extensions and pytest, developers can effortlessly create comprehensive tests. By leveraging these tools, broken links and endpoints can be identified, and potential errors can be caught before they have a chance to impact users.

Testing All Endpoints in Django: An Overview

WE ARE MIGRATING THE WEBSITE

You might be interested

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Clustering Users for Better Content Recommendations

Testing All Endpoints in Django: An Overview

Enhancing Android TV App Development: A Journey of Innovation and Improvement

Exploring Kotlin Multiplatform Mobile: A Comprehensive Overview

Clustering Users for Better Content Recommendations

Testing All Endpoints in Django: An Overview