Collaborer avec Slack en tant que développeur Open Source : partie 2

Récapitulatif de la première partie

Dans mon premier article de blog, j'ai partagé mon parcours de contribution au SDK Slack en tant que développeur open source. J'ai résolu un problème lié à la garantie que l'URL de base des requêtes API avait une barre oblique finale pour simplifier la construction de l'URL et éviter les incohérences. Si vous ne l'avez pas encore lu, je vous recommande de commencer par là pour avoir le contexte de ce suivi.

---

Un nouveau défi se présente

Après avoir terminé ma première contribution, j'avais hâte d'aborder un autre problème dans le même projet. Alors que je me préparais à commencer, j'ai remarqué un problème dans l'un des tests d'authentification. Le problème provenait de la fonctionnalité de barre oblique finale que j'avais précédemment implémentée.

Voici ce qui s'est passé : la base_url avait désormais toujours une barre oblique finale ajoutée lors de l'initialisation. Cependant, la méthode api_method utilisée dans certains cas de test commençait également par un /. Cette combinaison a provoqué une double barre oblique (par exemple, https://slack.com/api//auth.test), qui a interrompu certaines requêtes API.

---

Signaler le problème

Réalisant l'importance de ce bug, je l'ai rapidement signalé aux responsables et ouvert un nouveau numéro décrivant le problème. Pour garantir la transparence et fournir une solution claire, j'ai également soumis une pull request traitant du bug. Cependant, les responsables ont décidé d'annuler ma fusion d'origine pour éviter des perturbations dans la branche principale et m'ont demandé de soumettre un nouveau PR avec les correctifs et les tests nécessaires pour les cas extrêmes.

---

Le correctif et la nouvelle implémentation

Pour résoudre le problème, j'ai retravaillé la fonction _get_url et ajouté des protections supplémentaires pour éviter les doubles barres obliques, même lorsque base_url et api_method contenaient des barres obliques de fin ou de début.

Voici la mise en œuvre mise à jour :

def _get_url(base_url: str, api_method: str) -> str:
    """Joins the base Slack URL and an API method to form an absolute URL.

    Args:
        base_url (str): The base URL (always ends with '/').
        api_method (str): The Slack Web API method. e.g., 'chat.postMessage'.

    Returns:
        str: The absolute API URL, e.g., 'https://slack.com/api/chat.postMessage'.
    """
    # Strip leading slash from api_method to prevent double slashes
    api_method = api_method.lstrip("/")
    return urljoin(base_url, api_method)

---

Ajustements clés

1. Supprimer la barre oblique de début : en utilisant .lstrip("/") sur api_method, la fonction garantit qu'aucune double barre oblique ne se produit pendant la concaténation.
2. Améliorations des scénarios de test : j'ai étendu la suite de tests pour couvrir des scénarios tels que :
   • base_url avec et sans barre oblique finale.
   • api_method avec et sans barre oblique. Cas extrêmes où les deux avaient des barres obliques.

Voici un exemple du test mis à jour :

def test_get_url_prevent_double_slash(self):
    api_url = _get_url("https://slack.com/api/", "/auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should prevent double slashes")

    api_url = _get_url("https://slack.com/api", "auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should handle base_url without trailing slash")

    api_url = _get_url("https://slack.com/api/", "auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should handle api_method without leading slash")

    api_url = _get_url("https://slack.com/api", "/auth.test")
    self.assertEqual(api_url, "https://slack.com/api/auth.test", "Should handle both inputs cleanly")

---

Réflexions sur les tests et les cas extrêmes

Cette expérience m'a appris l'importance de tests approfondis. Même si mon implémentation d'origine a réussi tous les tests existants, elle ne tenait pas compte de certains cas extrêmes, tels que les barres obliques dans api_method.

Voici mes principaux points à retenir :

1. Les tests unitaires ne sont pas infaillibles : Bien que les tests unitaires aident à détecter de nombreux problèmes, ils peuvent ne pas couvrir tous les cas extrêmes. Une fonctionnalité peut encore avoir des détails, surtout si les entrées varient considérablement.
2. Collaborer et communiquer : Signaler rapidement les bogues et discuter des solutions avec les responsables peuvent éviter des perturbations plus importantes. Leur décision d'annuler mes modifications a souligné l'importance de maintenir la stabilité de la branche principale.
3. Itérer et apprendre : Les contributions open source sont itératives. Chaque étape est une opportunité de s'améliorer, d'apprendre des retours et de renforcer vos pratiques de codage.

---

Pensées finales

Contribuer au SDK de Slack a été une expérience inestimable. Ce parcours, depuis la mise en œuvre d'une nouvelle fonctionnalité jusqu'à la résolution de ses effets secondaires involontaires, a mis en évidence les complexités du développement logiciel réel et l'esprit collaboratif de l'open source.

Si vous envisagez de contribuer à un projet open source, ne laissez pas la peur de commettre des erreurs vous retenir. Chaque bug, chaque correctif et chaque test écrit est une étape pour devenir un meilleur développeur.

Quels défis avez-vous rencontrés dans vos contributions open source ? Discutons-en dans les commentaires ci-dessous !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!