Get best of the week

Testar projetos sem dor. Relatório Yandex

Nós da equipe Yandex.Maps para iOS, criamos projetos de teste usando um pequeno plugin para CocoaPods e várias classes de utilitários. Criar um projeto é rápido e confiável. Mas talvez nos incomodemos demais e não seja tão difícil montar um projeto manualmente com as configurações e dependências necessárias? No relatório, fui pelo contrário: primeiro observei o processo manual, depois o nosso.


- Primeiro, um pouco de fundo. Os Yandex.Maps são coletados por mais de um minuto. No meu computador, a criação do aplicativo leva um pouco mais de três minutos. Desenvolvemos projetos de teste para gastar menos tempo em cada montagem. Temos modularidade suficiente e, para cada módulo, estamos fazendo um projeto de teste. Neste projeto de teste, os recursos estão sendo desenvolvidos.

Criar um projeto de teste agora leva de 15 minutos a uma hora. Isso se deve ao fato de que o projeto deve ser configurado. Ou seja, você precisa configurar a assinatura para que possamos desenvolver nos mesmos dispositivos com os quais estamos acostumados. É necessário configurar as bibliotecas necessárias. No processo de desenvolvimento do próprio recurso, constantemente retornamos e concluímos o projeto de teste para que ele atenda às nossas necessidades.

Por que precisamos de projetos de teste? Para economizar tempo na montagem. Quanto menor o projeto, mais rápido ele é montado, mais frequentemente poderemos lançar nosso aplicativo no dispositivo e mais confortável será para o desenvolvimento.



O que deve estar no projeto de teste? Deveríamos ser capazes de iniciar, depurar nosso aplicativo nos mesmos dispositivos em que estamos acostumados a iniciar e depurar nosso aplicativo principal.

O projeto deve ser configurado o mais semelhante possível ao projeto principal, para que, no processo de transferência de recursos do projeto de teste para o principal, não tenhamos surpresa. Ou pelo menos reduziu ao mínimo o número de surpresas recebidas.

Também precisamos de um ambiente mínimo no projeto de teste, para não perder tempo criando o UIWindows, configurando bibliotecas, revertendo a chamada para abrir o aplicativo na biblioteca que lida com autorização, etc.

CocoaPods app_spec


Hoje, toda a minha história será construída em torno do recurso CocoaPods chamado app_spec.



App_spec é como um subespécie comum, mas não gera uma estrutura que possa ser conectada, mas um aplicativo que pode ser iniciado no dispositivo.



E pronto, CocoaPods nos permite inserir Info.plist e xcconfig em app_spec. Isso já nos permite montar nosso projeto muito bem.

Mas se vamos escrever dicionários enormes em cada pods_spec, com valores para Info.plist e xcconfig, aumentaremos o podspec por conta própria e será inconveniente modificá-los. Se precisarmos mudar alguma coisa, precisamos entrar em cada arquivo podspec e editar algo com canetas. De qualquer forma, isso é inconveniente.



Para nos livrarmos disso, criamos um plugin local muito simples para o CocoaPods. Até se encaixa inteiramente em um slide. E ele faz a única coisa: nos dá a permissão DSL CocoaPods, que cria app_spec com valores já entupidos no Info.plist e no xcconfig. Isso já nos permite configurar a assinatura, configurar as coisas importantes que queremos ver configuradas em nosso projeto de teste.



Pergunta: como transferir o caminho para direitos, mais precisamente, onde armazenar direitos para que possamos codificar o caminho em plug-ins.

Existem duas maneiras. Ou indique o caminho de um arquivo que simplesmente se encontra em nosso repositório, por exemplo, para os direitos do projeto principal. Ou armazene no plug-in um arquivo de direitos especiais para projetos de teste. E usando o mesmo plugin, copie-o para o nosso developmentpod.



Escolhemos o primeiro caminho, e aqui tivemos algumas dificuldades. O fato é que, em nosso repositório, os cododes de desenvolvimento estão em subpastas diferentes. Portanto, não podemos indicar um caminho relativo para eles, desde o developmentpod até o arquivo de autorizações.

É importante enfatizar aqui que você deve especificar um caminho relativo, porque esse caminho permanece em pods_spec. Isso significa que ele participará do cálculo do valor do cheque, armazenado no Podfile.lock. E se houver um caminho absoluto, isso afetará o valor do cheque. Isso significa que o valor do cheque variará dependendo de qual pasta chamar a instalação do $ pod, de onde você tem o repositório, em qual máquina você executa a instalação do $ pod. Em geral, isso leva a conflitos.



Agora vou mostrar outra pequena extensão do mesmo plugin, que nos permite calcular o caminho relativo a esses direitos.

Conhecemos o caminho relativo do nosso plug-in para o arquivo com direitos, se eles estiverem no mesmo repositório. E também durante o lançamento da instalação do $ pod, conhecemos o caminho para o nosso developmentpod. Toda a magia contida neste código é uma linha destacada, onde simplesmente contamos o caminho relativo, conhecendo esses dois caminhos absolutos.



Então, o que obtivemos quando já tínhamos app_spec configurado dessa maneira? Podemos executar nosso projeto de teste nos mesmos dispositivos imediatamente. Temos uma quantidade enorme de configurações, incluindo direitos, de que precisamos.

Meio Ambiente


A próxima coisa que quero falar é sobre o ambiente, o ambiente mínimo necessário para começar a escrever o código imediatamente.



No nosso caso, precisamos do MapKit, já configurado, com as chaves transferidas, com o encaminhamento de chamadas no AccountManager. Esta é a nossa biblioteca de autorização. Ela também precisa fazer chamadas do sistema, também precisa transferir chaves, inclusive para passar a abertura do aplicativo por referência.

Também precisamos de uma tela inicial com um mapa e uma pilha de navegação, para que possamos usar a mesma pilha de navegação que no Maps, e é mais fácil transferir recursos do projeto de teste para o principal. E o ponto de entrada para que, sem pensar, possamos começar imediatamente a escrever um código útil.



No seu caso, isso pode ser, por exemplo, configurar o SDK do Facebook, para o qual você também precisa transferir chaves; suas bibliotecas para logon, das quais você quase certamente precisará pular o link de abertura do aplicativo. Algum tipo de controlador de inicialização do Windows de inicialização e o mesmo ponto de entrada para executar o script principal que você deseja desenvolver em seu projeto de teste.



Como fizemos isso? Criando um único modelo AppDelegate. Lá inicializamos todos os ambientes necessários, bibliotecas. Encaminhamos todas as chamadas necessárias, transferimos as chaves necessárias. Criando um projeto de teste, resta criar um novo AppDelegate para o projeto de teste e herdar do modelo.

Depois disso, substituímos o único método chamado após o modelo AppDelegate ter feito todo o necessário. E já temos o ViewController inicial e, além disso, podemos executar nosso script, que queremos depurar no projeto de teste.

Foi / tornou-se


Como posso criar um projeto de teste na testa e como criá-lo usando o método que descrevi hoje?

Criando um projeto de teste na testa:

- Vamos ao Xcode, criamos um novo projeto (Arquivo> Novo Projeto).

- Digite o nome, de preferência sem erros, assine o ID do pacote. Estamos montando este projeto.

- Altere a versão do Swift, altere a versão de destino. Estamos tentando executar tudo no dispositivo, editar assinatura e assim por diante. Este é um processo bastante sombrio.

- Em seguida, criamos um podfile, conectamos dependências lá, instalamos pods.

- Depois disso, começamos a configurar o AppDelegate de maneira tediosa e delicada, transferindo as partes de inicialização das bibliotecas de que precisamos.

- Crie uma interface do usuário inicial do Windows com nosso ViewController

E somente depois disso podemos iniciar o código útil. Procedimento bastante desagradável, concordo.

Como podemos criar um projeto de teste usando as práticas recomendadas que descrevi no relatório de hoje?

- Criamos sample_app_spec, usando a extensão, para CocoaPods, com a qual começamos.

- Crie um AppDelegate e herde-o do modelo AppDelegate.

Depois disso, podemos começar a escrever código útil.

Criar um projeto de teste dessa maneira é muito mais rápido e mais confiável. Definitivamente, não cometeremos um erro nas configurações de assinatura, definitivamente não cometeremos um erro nas configurações do projeto. Todo o ambiente necessário para iniciar o trabalho imediatamente se aproxima de nós.

Isso pode ser mais fácil?


Você pode fazer uma pergunta - isso pode ser feito mais fácil? Claro.



Eu identifiquei três níveis de dificuldade. A primeira é sobre o que falei hoje, de uma só vez, quando criamos um plug-in bombeado para o CocoaPods, que pode reparar caminhos para direitos e um modelo AppDelegate.

O segundo método é ideal na proporção de esforços em relação ao lucro. Ele contém apenas o plug-in do CocoaPods, que foi o primeiro da história de hoje. Ou seja, ele simplesmente substitui os valores no Info.plist e no xcconfig. Já torna a vida muito mais fácil.

Se você não precisa do seu arquivo de direitos nos aplicativos de teste, se os aplicativos de teste são bastante diferentes entre si e não precisam de componentes comuns, esse método é muito adequado para você.

O terceiro método é o mais fácil, não requer nenhuma preparação. Basta começar a usar app_spec. O projeto gerado a partir do app_spec é criado no mesmo espaço de trabalho do seu projeto principal. Portanto, ele já herda, por exemplo, Swift, versão de destino e todas as configurações que você possui no Espaço de Trabalho. Será muito mais fácil para você começar a trabalhar com ele. Isso é tudo, obrigado pela atenção. Hoje eu vou lhe dizer como criar projetos de teste sem problemas e como criamos projetos de teste no Yandex.Maps.

- Primeiro, um pouco de fundo. Os Yandex.Maps são coletados por mais de um minuto. No meu computador, a criação do aplicativo leva um pouco mais de três minutos. Desenvolvemos projetos de teste para gastar menos tempo em cada montagem. Temos modularidade suficiente e, para cada módulo, estamos fazendo um projeto de teste. Neste projeto de teste, os recursos estão sendo desenvolvidos.

Criar um projeto de teste agora leva de 15 minutos a uma hora. Isso se deve ao fato de que o projeto deve ser configurado. Ou seja, você precisa configurar a assinatura para que possamos desenvolver nos mesmos dispositivos com os quais estamos acostumados. É necessário configurar as bibliotecas necessárias. No processo de desenvolvimento do próprio recurso, constantemente retornamos e concluímos o projeto de teste para que ele atenda às nossas necessidades.

Por que precisamos de projetos de teste? Para economizar tempo na montagem. Quanto menor o projeto, mais rápido ele é montado, mais frequentemente poderemos lançar nosso aplicativo no dispositivo e mais confortável será para o desenvolvimento.



O que deve estar no projeto de teste? Deveríamos ser capazes de iniciar, depurar nosso aplicativo nos mesmos dispositivos em que estamos acostumados a iniciar e depurar nosso aplicativo principal.

O projeto deve ser configurado o mais semelhante possível ao projeto principal, para que, no processo de transferência de recursos do projeto de teste para o principal, não tenhamos surpresa. Ou pelo menos reduziu ao mínimo o número de surpresas recebidas.

Também precisamos de um ambiente mínimo no projeto de teste, para não perder tempo criando o UIWindows, configurando bibliotecas, revertendo a chamada para abrir o aplicativo na biblioteca que lida com autorização, etc.

CocoaPods app_spec


Hoje, toda a minha história será construída em torno do recurso CocoaPods chamado app_spec.



App_spec é como um subespécie comum, mas não gera uma estrutura que possa ser conectada, mas um aplicativo que pode ser iniciado no dispositivo.



E pronto, CocoaPods nos permite inserir Info.plist e xcconfig em app_spec. Isso já nos permite montar nosso projeto muito bem.

Mas se vamos escrever dicionários enormes em cada pods_spec, com valores para Info.plist e xcconfig, aumentaremos o podspec por conta própria e será inconveniente modificá-los. Se precisarmos mudar alguma coisa, precisamos entrar em cada arquivo podspec e editar algo com canetas. Ou não canetas. De qualquer forma, isso é inconveniente.



Para nos livrarmos disso, criamos um plugin local muito simples para o CocoaPods. Até se encaixa inteiramente em um slide. E ele faz a única coisa: nos dá a permissão DSL CocoaPods, que cria app_spec com valores já entupidos no Info.plist e no xcconfig. Isso já nos permite configurar a assinatura, configurar as coisas importantes que queremos ver configuradas em nosso projeto de teste.



Pergunta: como transferir o caminho para direitos, mais precisamente, onde armazenar direitos para que possamos codificar o caminho em plug-ins.

Existem duas maneiras. Ou indique o caminho de um arquivo que simplesmente se encontra em nosso repositório, por exemplo, para os direitos do projeto principal. Ou armazene no plug-in um arquivo de direitos especiais para projetos de teste. E usando o mesmo plugin, copie-o para o nosso developmentpod.



Escolhemos o primeiro caminho, e aqui tivemos algumas dificuldades. O fato é que, em nosso repositório, os cododes de desenvolvimento estão em subpastas diferentes. Portanto, não podemos indicar um caminho relativo para eles, desde o developmentpod até o arquivo de autorizações.

É importante enfatizar aqui que você deve especificar um caminho relativo, porque esse caminho permanece em pods_spec. Isso significa que ele participará do cálculo do valor do cheque, armazenado no Podfile.lock. E se houver um caminho absoluto, isso afetará o valor do cheque. Isso significa que o valor do cheque variará dependendo de qual pasta chamar a instalação do $ pod, de onde você tem o repositório, em qual máquina você executa a instalação do $ pod. Em geral, isso leva a conflitos.



Agora vou mostrar outra pequena extensão do mesmo plugin, que nos permite calcular o caminho relativo a esses direitos.

Conhecemos o caminho relativo do nosso plug-in para o arquivo com direitos, se eles estiverem no mesmo repositório. E também durante o lançamento da instalação do $ pod, conhecemos o caminho para o nosso developmentpod. Toda a magia contida neste código é uma linha destacada, onde simplesmente contamos o caminho relativo, conhecendo esses dois caminhos absolutos.



Então, o que obtivemos quando já tínhamos app_spec configurado dessa maneira? Podemos executar nosso projeto de teste nos mesmos dispositivos imediatamente. Temos uma quantidade enorme de configurações, incluindo direitos, de que precisamos.

Meio Ambiente


A próxima coisa que quero falar é sobre o ambiente, o ambiente mínimo necessário para começar a escrever o código imediatamente.



No nosso caso, precisamos do MapKit, já configurado, com as chaves transferidas, com o encaminhamento de chamadas no AccountManager. Esta é a nossa biblioteca de autorização. Ela também precisa fazer chamadas do sistema, também precisa transferir chaves, inclusive para passar a abertura do aplicativo por referência.

Também precisamos de uma tela inicial com um mapa e uma pilha de navegação, para que possamos usar a mesma pilha de navegação que no Maps, e é mais fácil transferir recursos do projeto de teste para o principal. E o ponto de entrada para que, sem pensar, possamos começar imediatamente a escrever um código útil.



No seu caso, isso pode ser, por exemplo, configurar o SDK do Facebook, para o qual você também precisa transferir chaves; suas bibliotecas para logon, das quais você quase certamente precisará pular o link de abertura do aplicativo. Algum tipo de controlador de inicialização do Windows de inicialização e o mesmo ponto de entrada para executar o script principal que você deseja desenvolver em seu projeto de teste.



Como fizemos isso? Criando um único modelo AppDelegate. Lá inicializamos todos os ambientes necessários, bibliotecas. Encaminhamos todas as chamadas necessárias, transferimos as chaves necessárias. Criando um projeto de teste, resta criar um novo AppDelegate para o projeto de teste e herdar do modelo.

Depois disso, substituímos o único método chamado após o modelo AppDelegate ter feito todo o necessário. E já temos o ViewController inicial e, além disso, podemos executar nosso script, que queremos depurar no projeto de teste.

Foi / tornou-se


Como posso criar um projeto de teste na testa e como criá-lo usando o método que descrevi hoje?

Criando um projeto de teste na testa:

- Vamos ao Xcode, criamos um novo projeto (Arquivo> Novo Projeto).

- Digite o nome, de preferência sem erros, assine o ID do pacote. Estamos montando este projeto.

- Altere a versão do Swift, altere a versão de destino. Estamos tentando executar tudo no dispositivo, editar assinatura e assim por diante. Este é um processo bastante sombrio.

- Em seguida, criamos um podfile, conectamos dependências lá, instalamos pods.

- Depois disso, começamos a configurar o AppDelegate de maneira tediosa e delicada, transferindo as partes de inicialização das bibliotecas de que precisamos.

- Crie uma interface do usuário inicial do Windows com nosso ViewController

E somente depois disso podemos iniciar o código útil. Procedimento bastante desagradável, concordo.

Como podemos criar um projeto de teste usando as práticas recomendadas que descrevi no relatório de hoje?

- Criamos sample_app_spec, usando a extensão, para CocoaPods, com a qual começamos.

- Crie um AppDelegate e herde-o do modelo AppDelegate.

Depois disso, podemos começar a escrever código útil.

Criar um projeto de teste dessa maneira é muito mais rápido e mais confiável. Definitivamente, não cometeremos um erro nas configurações de assinatura, definitivamente não cometeremos um erro nas configurações do projeto. Todo o ambiente necessário para iniciar o trabalho imediatamente se aproxima de nós.

Isso pode ser mais fácil?


Você pode fazer uma pergunta - isso pode ser feito mais fácil? Claro.



Eu identifiquei três níveis de dificuldade. A primeira é sobre o que falei hoje, de uma só vez, quando criamos um plug-in bombeado para o CocoaPods, que pode reparar caminhos para direitos e um modelo AppDelegate.

O segundo método é ideal na proporção de esforços em relação ao lucro. Ele contém apenas o plug-in do CocoaPods, que foi o primeiro da história de hoje. Ou seja, ele simplesmente substitui os valores no Info.plist e no xcconfig. Já torna a vida muito mais fácil.

Se você não precisa do seu arquivo de direitos nos aplicativos de teste, se os aplicativos de teste são bastante diferentes entre si e não precisam de componentes comuns, esse método é muito adequado para você.

O terceiro método é o mais fácil, não requer nenhuma preparação. Basta começar a usar app_spec. O projeto gerado a partir do app_spec é criado no mesmo espaço de trabalho do seu projeto principal. Portanto, ele já herda a versão Swift, a versão de destino e todas as configurações que você possui no Espaço de Trabalho. Será muito mais fácil para você começar a trabalhar com ele.
Obrigado pela atenção.

More articles:


All Articles