Get best of the week

Testez des projets sans douleur. Rapport Yandex

Nous, dans l'équipe Yandex.Maps pour iOS, créons des projets de test en utilisant un petit plugin pour CocoaPods et plusieurs classes d'utilitaires. La création d'un projet est rapide et fiable. Mais peut-être nous dérange-t-on trop et ce n'est pas si difficile d'assembler un projet manuellement avec les paramètres et les dépendances nécessaires? Dans le rapport, je suis allé du contraire: j'ai d'abord regardé le processus manuel, puis le nôtre.


- D'abord, un peu d'histoire. Yandex.Les cartes sont collectées pendant plus d'une minute. Sur mon ordinateur, la création de l'application prend un peu plus de trois minutes. Nous développons des projets de test afin de passer moins de temps sur chaque montage. Nous avons suffisamment de modularité, et pour chaque module, nous faisons un projet de test. Dans ce projet de test, des fonctionnalités sont en cours de développement.

La création d'un projet de test prend désormais de 15 minutes à une heure. Cela est dû au fait que le projet doit être configuré. Autrement dit, vous devez configurer la signature afin que nous puissions développer sur les mêmes appareils que ceux auxquels nous sommes habitués. Il est nécessaire de configurer les bibliothèques nécessaires. Dans le processus de développement de la fonctionnalité elle-même, nous revenons constamment et terminons le projet de test afin qu'il réponde à nos besoins.

Pourquoi avons-nous besoin de projets de test? Pour gagner du temps lors du montage. Plus le projet est petit, plus il est assemblé rapidement, plus nous serons en mesure de lancer notre application sur l'appareil et plus il sera confortable pour nous de le développer.



Que devrait contenir le projet de test? Nous devrions pouvoir lancer, déboguer notre application sur les mêmes appareils sur lesquels nous sommes habitués à lancer et déboguer notre application principale.

Le projet doit être configuré de manière aussi similaire que possible au projet principal, de sorte que lors du transfert des fonctionnalités du projet de test vers le projet principal, nous n'obtenions pas de surprise. Ou du moins réduit le nombre de surprises reçues au minimum.

Nous avons également besoin d'un environnement minimal dans le projet de test, afin de ne pas perdre de temps à créer des fenêtres d'interface utilisateur, à configurer des bibliothèques, à annuler l'appel pour ouvrir l'application à la bibliothèque qui traite des autorisations, etc.

CocoaPods app_spec


Toute mon histoire d'aujourd'hui sera construite autour de la fonctionnalité CocoaPods appelée app_spec.



App_spec est comme une sous-espèce régulière, seulement elle ne génère pas un framework qui peut être connecté, mais une application qui peut être lancée sur l'appareil.



Et prêt à l'emploi, CocoaPods nous permet de placer Info.plist et xcconfig dans app_spec. Cela nous permet déjà de bien monter notre projet.

Mais si nous allons écrire d'énormes dictionnaires dans chaque pods_spec, avec des valeurs pour Info.plist et xcconfig, alors nous développerons podspec nous-mêmes et il ne sera pas pratique de les modifier. Si nous devons changer quelque chose, nous devons aller dans chaque fichier podspec et éditer quelque chose avec des stylos. Dans tous les cas, cela n'est pas pratique.



Pour nous en débarrasser, nous avons créé un plugin local très simple pour CocoaPods. Il tient même entièrement dans une diapositive. Et il fait la seule et unique chose: nous donne la permission DSL CocoaPods, qui crée app_spec avec des valeurs déjà bouchées dans Info.plist et xcconfig. Cela nous permet déjà de configurer la signature, de configurer les choses importantes que nous voulons voir configurées dans notre projet de test.



Question: comment transférer le chemin d'accès aux droits d'accès, plus précisément, où stocker les droits d'accès afin que nous puissions coder en dur le chemin d'accès dans les plug-ins.

Il y a deux façons. Ou indiquez le chemin d'un fichier qui se trouve simplement dans notre référentiel, par exemple, vers les droits du projet principal. Ou stockez dans le plugin un fichier de droits spéciaux pour les projets de test. Et en utilisant le même plugin, copiez-le sur notre developmentpod.



Nous avons choisi la première voie, et ici nous avons eu quelques difficultés. Le fait est que dans notre référentiel, les modules de développement se trouvent dans différents sous-dossiers. Par conséquent, nous ne pouvons pas leur indiquer un chemin d'accès relatif depuis le développementpod vers le fichier de droits.

Il est important de souligner ici que vous devez spécifier un chemin relatif, car ce chemin reste dans pods_spec. Cela signifie qu'il participera au calcul du montant du chèque, qui est stocké dans Podfile.lock. Et s'il existe un chemin absolu, cela affectera le montant du chèque. Cela signifie que le montant du chèque variera en fonction du dossier à partir duquel $ pod installer, d'où vous avez le référentiel, sur quelle machine vous exécutez $ pod install. En général, cela conduit à des conflits.



Maintenant, je vais montrer une autre petite extension du même plugin, qui nous permet de calculer le chemin relatif vers ces droits.

Nous connaissons le chemin relatif de notre plugin vers le fichier avec des droits, s'ils sont dans le même référentiel. Et aussi lors du lancement de $ pod install, nous connaissons le chemin vers notre developmentpod. Toute la magie qui se trouve dans ce code est une ligne en surbrillance où nous comptons simplement le chemin relatif, connaissant ces deux chemins absolus.



Alors, qu'avons-nous obtenu lorsque nous avions déjà configuré app_spec de cette manière? Nous pouvons exécuter notre projet de test sur les mêmes appareils immédiatement. Nous avons obtenu une énorme quantité de paramètres, y compris les droits, dont nous avons besoin.

Environnement


La prochaine chose dont je veux parler est l'environnement, l'environnement minimum nécessaire dont nous avons besoin pour commencer à écrire du code tout de suite.



Dans notre cas, nous avons besoin de MapKit, déjà configuré, avec les clés transférées, avec renvoi d'appel dans le AccountManager. Ceci est notre bibliothèque d'autorisation. Elle doit également lancer des appels système, elle doit également transférer des clés, notamment pour passer l'ouverture de l'application par référence.

Nous avons également besoin d'un écran de démarrage avec une carte et une pile de navigation, afin de pouvoir utiliser la même pile de navigation que dans Maps, et il est plus facile de transférer des fonctionnalités du projet de test vers le projet principal. Et le point d'entrée pour que nous, sans réfléchir, puissions immédiatement commencer à écrire du code utile.



Dans votre cas, cela pourrait être, par exemple, la configuration du SDK Facebook, auquel vous devez également transférer des clés; vos bibliothèques pour la connexion, dont vous aurez presque certainement besoin pour sauter le lien d'ouverture de l'application. Une sorte de contrôleur de démarrage Windows de démarrage et le même point d'entrée pour exécuter le script principal que vous souhaitez développer dans votre projet de test.



Comment avons-nous fait cela? En créant un seul modèle AppDelegate. Là, nous initialisons tous les environnements nécessaires, les bibliothèques. Nous renvoyons tous les appels nécessaires, transférons les clés nécessaires. En créant un projet de test, il nous reste à créer un nouveau AppDelegate pour le projet de test et à hériter du modèle.

Après cela, nous remplaçons la seule et unique méthode appelée après que le modèle AppDelegate a fait tout ce qui était nécessaire. Et là, nous avons déjà le ViewController de départ et en plus nous pouvons exécuter notre script, que nous voulons déboguer dans le projet de test.

Était / est devenu


Comment puis-je créer un projet de test dans le front et comment le créer en utilisant la méthode que j'ai décrite aujourd'hui?

Création d'un projet de test dans le front:

- Nous allons dans Xcode, créons un nouveau projet (Fichier> Nouveau projet).

- Saisissez le nom, de préférence sans erreur, signez le Bundle ID. Nous mettons en place ce projet.

- Changez la version de Swift, changez la version cible. Nous essayons de tout exécuter sur l'appareil, de modifier la signature, etc. C'est un processus plutôt morne.

- Ensuite, nous créons un podfile, y connectons les dépendances, installons des pods.

- Après cela, nous allons commencer à configurer très fastidieusement et doucement notre AppDelegate, en transférant à travers les morceaux d'initialisation des bibliothèques dont nous avons besoin.

- Créez un UIWindows de démarrage avec notre ViewController

Et seulement après cela, nous pouvons démarrer le code utile. Procédure assez désagréable, d'accord.

Comment pouvons-nous créer un projet de test en utilisant les meilleures pratiques que j'ai décrites dans le rapport d'aujourd'hui?

- Nous créons sample_app_spec, en utilisant l'extension, pour CocoaPods, avec lequel nous avons commencé.

- Créez un AppDelegate et héritez-le du modèle AppDelegate.

Après cela, nous pouvons commencer à écrire du code utile.

La création d'un projet de test de cette manière est beaucoup plus rapide et plus fiable. Nous ne ferons certainement pas d'erreur dans la signature des paramètres, nous ne ferons certainement pas d'erreur dans les paramètres du projet. Tout l'environnement nécessaire au démarrage des travaux nous approche immédiatement.

Cela peut-il être plus simple?


Vous pouvez poser une question - cela peut-il être plus facile? Bien sûr.



J'ai identifié trois niveaux de difficulté. Le premier est ce dont j'ai parlé aujourd'hui, tout à coup, lorsque nous créons un plug-in pour CocoaPods, qui peut réparer les chemins d'accès aux droits, et un modèle AppDelegate.

La deuxième méthode est idéale dans le rapport des efforts au profit. Il ne contient que le plugin pour CocoaPods, qui était le premier dans l'histoire d'aujourd'hui. Autrement dit, il remplace simplement les valeurs dans Info.plist et xcconfig. Cela rend déjà la vie beaucoup plus facile.

Si vous n'avez pas besoin de votre fichier de droits dans vos applications de test, si vos applications de test sont assez différentes les unes des autres et n'ont pas besoin de composants communs, cette méthode vous convient parfaitement.

La troisième méthode est la plus simple, ne nécessite aucune préparation. Commencez simplement à utiliser app_spec. Le projet généré à partir de app_spec est créé dans le même espace de travail que votre projet principal. Par conséquent, il hérite déjà, par exemple, Swift, de la version cible et de tous les paramètres que vous avez dans Workspace. Il vous sera beaucoup plus facile de commencer à travailler avec lui. C'est tout, merci de votre attention. Aujourd'hui, je vais vous dire comment créer des projets de test sans douleur, et comment nous créons des projets de test dans Yandex.Maps.

- D'abord, un peu d'histoire. Yandex.Les cartes sont collectées pendant plus d'une minute. Sur mon ordinateur, la création de l'application prend un peu plus de trois minutes. Nous développons des projets de test afin de passer moins de temps sur chaque montage. Nous avons suffisamment de modularité, et pour chaque module, nous faisons un projet de test. Dans ce projet de test, des fonctionnalités sont en cours de développement.

La création d'un projet de test prend désormais de 15 minutes à une heure. Cela est dû au fait que le projet doit être configuré. Autrement dit, vous devez configurer la signature afin que nous puissions développer sur les mêmes appareils que ceux auxquels nous sommes habitués. Il est nécessaire de configurer les bibliothèques nécessaires. Dans le processus de développement de la fonctionnalité elle-même, nous revenons constamment et terminons le projet de test afin qu'il réponde à nos besoins.

Pourquoi avons-nous besoin de projets de test? Pour gagner du temps lors du montage. Plus le projet est petit, plus il est assemblé rapidement, plus nous serons en mesure de lancer notre application sur l'appareil et plus il sera confortable pour nous de le développer.



Que devrait contenir le projet de test? Nous devrions pouvoir lancer, déboguer notre application sur les mêmes appareils sur lesquels nous sommes habitués à lancer et déboguer notre application principale.

Le projet doit être configuré de manière aussi similaire que possible au projet principal, de sorte que lors du transfert des fonctionnalités du projet de test vers le projet principal, nous n'obtenions pas de surprise. Ou du moins réduit le nombre de surprises reçues au minimum.

Nous avons également besoin d'un environnement minimal dans le projet de test, afin de ne pas perdre de temps à créer des fenêtres d'interface utilisateur, à configurer des bibliothèques, à annuler l'appel à ouvrir l'application dans la bibliothèque qui traite des autorisations, etc.

CocoaPods app_spec


Toute mon histoire d'aujourd'hui sera construite autour de la fonctionnalité CocoaPods appelée app_spec.



App_spec est comme une sous-espèce régulière, seulement elle ne génère pas un framework qui peut être connecté, mais une application qui peut être lancée sur l'appareil.



Et prêt à l'emploi, CocoaPods nous permet de placer Info.plist et xcconfig dans app_spec. Cela nous permet déjà de bien monter notre projet.

Mais si nous allons écrire d'énormes dictionnaires dans chaque pods_spec, avec des valeurs pour Info.plist et xcconfig, alors nous développerons podspec nous-mêmes et il ne sera pas pratique de les modifier. Si nous devons changer quelque chose, nous devons aller dans chaque fichier podspec et éditer quelque chose avec des stylos. Ou pas des stylos. Dans tous les cas, cela n'est pas pratique.



Pour nous en débarrasser, nous avons créé un plugin local très simple pour CocoaPods. Il tient même entièrement dans une diapositive. Et il fait la seule et unique chose: nous donne la permission DSL CocoaPods, qui crée app_spec avec des valeurs déjà bouchées dans Info.plist et xcconfig. Cela nous permet déjà de configurer la signature, de configurer les choses importantes que nous voulons voir configurées dans notre projet de test.



Question: comment transférer le chemin d'accès aux droits d'accès, plus précisément, où stocker les droits d'accès afin que nous puissions coder en dur le chemin d'accès dans les plug-ins.

Il y a deux façons. Ou indiquez le chemin d'un fichier qui se trouve simplement dans notre référentiel, par exemple, vers les droits du projet principal. Ou stockez dans le plugin un fichier de droits spéciaux pour les projets de test. Et en utilisant le même plugin, copiez-le sur notre developmentpod.



Nous avons choisi la première voie, et ici nous avons eu quelques difficultés. Le fait est que dans notre référentiel, les modules de développement se trouvent dans différents sous-dossiers. Par conséquent, nous ne pouvons pas leur indiquer un chemin d'accès relatif depuis le développementpod vers le fichier de droits.

Il est important de souligner ici que vous devez spécifier un chemin relatif, car ce chemin reste dans pods_spec. Cela signifie qu'il participera au calcul du montant du chèque, qui est stocké dans Podfile.lock. Et s'il existe un chemin absolu, cela affectera le montant du chèque. Cela signifie que le montant du chèque variera en fonction du dossier à partir duquel $ pod installer, d'où vous avez le référentiel, sur quelle machine vous exécutez $ pod install. En général, cela conduit à des conflits.



Maintenant, je vais montrer une autre petite extension du même plugin, qui nous permet de calculer le chemin relatif vers ces droits.

Nous connaissons le chemin relatif de notre plugin vers le fichier avec des droits, s'ils sont dans le même référentiel. Et aussi lors du lancement de $ pod install, nous connaissons le chemin vers notre developmentpod. Toute la magie qui se trouve dans ce code est une ligne en surbrillance où nous comptons simplement le chemin relatif, connaissant ces deux chemins absolus.



Alors, qu'avons-nous obtenu lorsque nous avions déjà configuré app_spec de cette manière? Nous pouvons exécuter notre projet de test sur les mêmes appareils immédiatement. Nous avons obtenu une énorme quantité de paramètres, y compris les droits, dont nous avons besoin.

Environnement


La prochaine chose dont je veux parler est l'environnement, l'environnement minimum nécessaire dont nous avons besoin pour commencer à écrire du code tout de suite.



Dans notre cas, nous avons besoin de MapKit, déjà configuré, avec les clés transférées, avec renvoi d'appel dans le AccountManager. Ceci est notre bibliothèque d'autorisation. Elle doit également lancer des appels système, elle doit également transférer des clés, notamment pour passer l'ouverture de l'application par référence.

Nous avons également besoin d'un écran de démarrage avec une carte et une pile de navigation, afin de pouvoir utiliser la même pile de navigation que dans Maps, et il est plus facile de transférer des fonctionnalités du projet de test vers le projet principal. Et le point d'entrée pour que nous, sans réfléchir, puissions immédiatement commencer à écrire du code utile.



Dans votre cas, cela pourrait être, par exemple, la configuration du SDK Facebook, auquel vous devez également transférer des clés; vos bibliothèques pour la connexion, dont vous aurez presque certainement besoin pour sauter le lien d'ouverture de l'application. Une sorte de contrôleur de démarrage Windows de démarrage et le même point d'entrée pour exécuter le script principal que vous souhaitez développer dans votre projet de test.



Comment avons-nous fait cela? En créant un seul modèle AppDelegate. Là, nous initialisons tous les environnements nécessaires, les bibliothèques. Nous renvoyons tous les appels nécessaires, transférons les clés nécessaires. En créant un projet de test, il nous reste à créer un nouveau AppDelegate pour le projet de test et à hériter du modèle.

Après cela, nous remplaçons la seule et unique méthode appelée après que le modèle AppDelegate a fait tout ce qui était nécessaire. Et là, nous avons déjà le ViewController de départ et en plus nous pouvons exécuter notre script, que nous voulons déboguer dans le projet de test.

Était / est devenu


Comment puis-je créer un projet de test dans le front et comment le créer en utilisant la méthode que j'ai décrite aujourd'hui?

Création d'un projet de test dans le front:

- Nous allons dans Xcode, créons un nouveau projet (Fichier> Nouveau projet).

- Saisissez le nom, de préférence sans erreur, signez le Bundle ID. Nous mettons en place ce projet.

- Changez la version de Swift, changez la version cible. Nous essayons de tout exécuter sur l'appareil, de modifier la signature, etc. C'est un processus plutôt morne.

- Ensuite, nous créons un podfile, y connectons les dépendances, installons des pods.

- Après cela, nous allons commencer à configurer très fastidieusement et doucement notre AppDelegate, en transférant à travers les morceaux d'initialisation des bibliothèques dont nous avons besoin.

- Créez un UIWindows de démarrage avec notre ViewController

Et seulement après cela, nous pouvons démarrer le code utile. Procédure assez désagréable, d'accord.

Comment pouvons-nous créer un projet de test en utilisant les meilleures pratiques que j'ai décrites dans le rapport d'aujourd'hui?

- Nous créons sample_app_spec, en utilisant l'extension, pour CocoaPods, avec lequel nous avons commencé.

- Créez un AppDelegate et héritez-le du modèle AppDelegate.

Après cela, nous pouvons commencer à écrire du code utile.

La création d'un projet de test de cette manière est beaucoup plus rapide et plus fiable. Nous ne ferons certainement pas d'erreur dans la signature des paramètres, nous ne ferons certainement pas d'erreur dans les paramètres du projet. Tout l'environnement nécessaire au démarrage des travaux nous approche immédiatement.

Cela peut-il être plus simple?


Vous pouvez poser une question - cela peut-il être plus facile? Bien sûr.



J'ai identifié trois niveaux de difficulté. Le premier est ce dont j'ai parlé aujourd'hui, tout à coup, lorsque nous créons un plug-in pour CocoaPods, qui peut réparer les chemins d'accès aux droits, et un modèle AppDelegate.

La deuxième méthode est idéale dans le rapport des efforts au profit. Il ne contient que le plugin pour CocoaPods, qui était le premier dans l'histoire d'aujourd'hui. Autrement dit, il remplace simplement les valeurs dans Info.plist et xcconfig. Cela rend déjà la vie beaucoup plus facile.

Si vous n'avez pas besoin de votre fichier de droits dans vos applications de test, si vos applications de test sont assez différentes les unes des autres et n'ont pas besoin de composants communs, cette méthode vous convient parfaitement.

La troisième méthode est la plus simple, ne nécessite aucune préparation. Commencez simplement à utiliser app_spec. Le projet généré à partir de app_spec est créé dans le même espace de travail que votre projet principal. Par conséquent, il hérite déjà de la version Swift, de la version cible et de tous les paramètres que vous avez dans Workspace. Il vous sera beaucoup plus facile de commencer à travailler avec lui.
Merci pour l'attention.

More articles:


All Articles