Pruebas estáticas o guardar al soldado Ryan

Un lanzamiento a menudo pasa desapercibido. Y cualquier error que se descubrió de repente frente a él nos amenaza con un cambio en los plazos, las revisiones, el trabajo hasta la mañana y los nervios. Cuando tal apuro comenzó a ocurrir sistemáticamente, nos dimos cuenta de que ya no puedes vivir así. Se decidió desarrollar un sistema de validación integral para salvar al desarrollador ordinario de Ryan , Artyom, que se fue a su casa antes del lanzamiento a las 9 p.m., a las 10 o a las 11 ... bueno, entiendes. La idea era que el desarrollador descubriera el error, mientras que los cambios aún no habían llegado al repositorio, y él mismo no había perdido el contexto de la tarea.


Hoy, los cambios realizados se comprueban cuidadosamente primero localmente y luego con una serie de pruebas de integración en la granja de ensamblado. En este artículo, hablaremos sobre la primera etapa de verificación: pruebas estáticas, que monitorean la corrección de los recursos y analizan el código. Este es el primer subsistema de la cadena y representa la mayor parte de los errores encontrados.

Como empezó todo

El proceso manual de verificar el juego antes del lanzamiento comenzó en QA una semana y media antes del lanzamiento. Naturalmente, los errores que se encuentran en esta etapa deben corregirse lo antes posible.

Debido a la falta de tiempo para una buena solución, se agrega una "muleta" temporal, que luego se arraiga durante mucho tiempo y está rodeada de otras soluciones no muy populares.

En primer lugar, decidimos automatizar el hallazgo de errores evidentes: bloqueos, incapacidad para completar el conjunto principal de acciones para el juego (abrir una tienda, hacer una compra, jugar un nivel). Para hacer esto, el juego comienza en un modo especial de juego automático y si algo sale mal, lo sabremos inmediatamente después de pasar la prueba en nuestra granja.

Pero la mayoría de los errores que encontraron tanto los probadores como nuestra prueba de humo automatizada fueron la falta de un recurso o la configuración incorrecta de diferentes sistemas. Por lo tanto, el siguiente paso fue la prueba estática : verificar la disponibilidad de recursos, sus relaciones y configuraciones sin iniciar la aplicación. Este sistema fue lanzado por un paso adicional en la granja de ensamblaje y simplificó enormemente la búsqueda y corrección de errores. Pero, ¿por qué desperdiciar los recursos de la granja de ensamblados si puede detectar un error incluso antes de confirmar y obtener el código del problema en el repositorio? Esto se puede hacer con ganchos de precompromiso , que se inician antes de que se cree el compromiso y se envíe al repositorio.

Y sí, somos tan geniales que las pruebas estáticas antes de comprometerse y en la granja de ensamblados se realizan con un código, lo que simplifica enormemente su soporte.

Nuestros esfuerzos se pueden dividir en tres áreas:

• creación de una granja de ensamblaje: el mismo lugar donde se recolectará todo lo que se ha recolectado y verificado;
• desarrollo de pruebas estáticas: verificar la exactitud de los recursos, sus relaciones, lanzar analizadores de código;
• desarrollo de pruebas de tiempo de ejecución: lanzamiento de la aplicación en modo de reproducción automática.

Una tarea separada era organizar el lanzamiento de pruebas en la máquina del desarrollador. Era necesario minimizar el tiempo de ejecución localmente (el desarrollador no tiene que esperar 10 minutos para confirmar una línea) y asegurarse de que cada sistema que realiza los cambios tenga instalado nuestro sistema.

Muchos requisitos: un sistema

Durante el desarrollo, hay un conjunto completo de ensamblajes que pueden ser útiles: con y sin trampas, beta o alfa, iOS o Android. En cada caso, se pueden necesitar diferentes recursos, configuraciones o incluso códigos diferentes. Escribir scripts para pruebas estáticas para cada posible ensamblaje da como resultado un sistema complejo con muchos parámetros. Además de ser difícil de mantener y modificar, cada proyecto también tiene su propio conjunto de bicicletas con muletas.

A través de prueba y error, llegamos a un sistema, cada prueba en la que puede tener en cuenta el contexto de lanzamiento y decidir si ejecutarlo o no, qué exactamente y cómo verificarlo. Al comienzo de las pruebas, identificamos tres propiedades principales:

• tipo de ensamblaje: para los recursos de liberación y depuración, las verificaciones diferirán en términos de rigor, integridad de la cobertura, así como configuraciones para identificadores y verificación de la funcionalidad disponible;
• plataforma: lo que es válido para Android puede ser incorrecto para iOS, los recursos también se recopilan de manera diferente y no todos los recursos en la versión de Android estarán en iOS y viceversa;
• ubicación de lanzamiento: dónde exactamente estamos lanzando: en el agente de compilación donde se necesitan todas las pruebas disponibles o en la computadora del usuario donde se debe minimizar la lista de startups.

Sistema de prueba estática

El núcleo del sistema y el conjunto básico de pruebas estáticas se implementan en python. La base es solo unas pocas entidades:


El contexto de prueba es un concepto extenso. Almacena tanto los parámetros de compilación como de lanzamiento, de los que hablamos anteriormente, así como la metainformación que las pruebas llenan y usan.

Primero debe comprender qué pruebas ejecutar. Para esto, la metainformación contiene los tipos de recursos que nos interesan específicamente en este lanzamiento. Los tipos de recursos están determinados por las pruebas registradas en el sistema. Una prueba se puede "asociar" con un solo tipo o varios, y si, en el momento de la confirmación, resulta que los archivos que verifica esta prueba han cambiado, entonces el recurso asociado ha cambiado. Esto se adapta convenientemente a nuestra ideología: ejecutar localmente la menor cantidad de comprobaciones posibles: si los archivos de los que es responsable la prueba no han cambiado, entonces no es necesario ejecutarlos.

Por ejemplo, hay una descripción del pez, en la que se indican el modelo 3D y la textura. Si el archivo de descripción ha cambiado, se verifica que el modelo y la textura indicados existen. En otros casos, no es necesario ejecutar un control de peces.

Por otro lado, cambiar un recurso puede requerir cambios y entidades dependiendo de él: si el conjunto de texturas que almacenamos en archivos xml ha cambiado, entonces es necesario verificar modelos 3D adicionales, ya que puede resultar que la textura que necesita se elimine. Las optimizaciones descritas anteriormente se aplican solo localmente en la máquina del usuario en el momento de la confirmación, y cuando se inicia en la granja de ensamblados, se supone que todos los archivos han cambiado y ejecutamos todas las pruebas.

El siguiente problema es la dependencia de algunas pruebas en otras: es imposible verificar el pescado antes de encontrar todas las texturas y modelos. Por lo tanto, dividimos toda la ejecución en dos etapas:

• preparación de contexto
• comprobando

En la primera etapa, el contexto se llena con información sobre los recursos encontrados (en el caso de los peces, con identificadores de patrones y texturas). En la segunda etapa, utilizando la información almacenada, simplemente verifique si existe el recurso deseado. Un contexto simplificado se presenta a continuación.

class VerificationContext(object):   def __init__(self, app_path, build_type, platform, changed_files=None):       self.__app_path = app_path       self.__build_type = build_type       self.__platform = platform       #          self.__modified_resources = set()       self.__expected_resources = set()       #      ,              self.__changed_files = changed_files       # -  ,          self.__resources = {} def expect_resources(self, resources):   self.__expected_resources.update(resources) def is_resource_expected(self, resource):   return resource in self.__expected_resources def register_resource(self, resource_type, resource_id, resource_data=None):   self.__resources.setdefault(resource_type, {})[resource_id] = resource_data def get_resource(self, resource_type, resource_id):   if resource_type not in self.__resources or resource_id not in self.__resources[resource_type]:       return None, None   return resource_id, self.__resources[resource_type][resource_id] 

Habiendo determinado todos los parámetros que afectan el lanzamiento de la prueba, logramos ocultar toda la lógica dentro de la clase base. En una prueba específica, queda por escribir solo la prueba misma y los valores necesarios para los parámetros.

 class TestCase(object):  def __init__(self, name, context, build_types=None, platforms=None, predicate=None,               expected_resources=None, modified_resources=None):      self.__name = name      self.__context = context      self.__build_types = build_types      self.__platforms = platforms      self.__predicate = predicate      self.__expected_resources = expected_resources      self.__modified_resources = modified_resources      #               #   ,          self.__need_run = self.__check_run()      self.__need_resource_run = False  @property  def context(self):      return self.__context  def fail(self, message):      print('Fail: {}'.format(message))  def __check_run(self):      build_success = self.__build_types is None or self.__context.build_type in self.__build_types      platform_success = self.__platforms is None or self.__context.platform in self.__platforms      hook_success = build_success      if build_success and self.__context.is_build('hook') and self.__predicate:          hook_success = any(self.__predicate(changed_file) for changed_file in self.__context.changed_files)      return build_success and platform_success and hook_success  def __set_context_resources(self):      if not self.__need_run:          return      if self.__modified_resources:          self.__context.modify_resources(self.__modified_resources)      if self.__expected_resources:          self.__context.expect_resources(self.__expected_resources)   def init(self):      """        ,                    ,          """      self.__need_resource_run = self.__modified_resources and any(self.__context.is_resource_expected(resource) for resource in self.__modified_resources)  def _prepare_impl(self):      pass  def prepare(self):      if not self.__need_run and not self.__need_resource_run:          return      self._prepare_impl()  def _run_impl(self):      pass  def run(self):      if self.__need_run:          self._run_impl() 

Volviendo al ejemplo de los peces, necesitamos dos pruebas, una de las cuales encuentra texturas y las registra en contexto, la otra busca texturas para los modelos encontrados.

 class VerifyTexture(TestCase):  def __init__(self, context):      super(VerifyTexture, self).__init__('VerifyTexture', context,                                          build_types=['production', 'hook'],                                          platforms=['windows', 'ios'],                                          expected_resources=None,                                          modified_resources=['Texture'],                                          predicate=lambda file_path: os.path.splitext(file_path)[1] == '.png')  def _prepare_impl(self):      texture_dir = os.path.join(self.context.app_path, 'resources', 'textures')      for root, dirs, files in os.walk(texture_dir):          for tex_file in files:              self.context.register_resource('Texture', tex_file) class VerifyModels(TestCase):  def __init__(self, context):      super(VerifyModels, self).__init__('VerifyModels', context,                                         expected_resources=['Texture'],                                         predicate=lambda file_path: os.path.splitext(file_path)[1] == '.obj')  def _run_impl(self):      models_descriptions = etree.parse(os.path.join(self.context.app_path, 'resources', 'models.xml'))      for model_xml in models_descriptions.findall('.//Model'):          texture_id = model_xml.get('texture')          texture = self.context.get_resource('Texture', texture_id)          if texture is None:              self.fail('Texture for model {} was not found: {}'.format(model_xml.get('id'), texture_id)) 

Proyecto extendido

El desarrollo del juego en Playrix se lleva a cabo en su propio motor y, en consecuencia, todos los proyectos tienen una estructura de archivo y un código similares utilizando las mismas reglas. Por lo tanto, hay muchas pruebas generales que se escriben una vez y están en el código general. Es suficiente que los proyectos actualicen la versión del sistema de prueba y se conecten una nueva prueba.

Para simplificar la integración, escribimos un corredor que recibe el archivo de configuración y las pruebas de diseño (sobre ellos más adelante). El archivo de configuración contiene información básica sobre la que escribimos anteriormente: tipo de ensamblaje, plataforma, ruta al proyecto.

 class Runner(object):  def __init__(self, config_str, setup_function):      self.__tests = []      config_parser = RawConfigParser()      config_parser.read_string(config_str)      app_path = config_parser.get('main', 'app_path')      build_type = config_parser.get('main', 'build_type')      platform = config_parser.get('main', 'platform')      '''      get_changed_files         CVS      '''      changed_files = None if build_type != 'hook' else get_changed_files()      self.__context = VerificationContext(app_path, build_type, platform, changed_files)      setup_function(self)  @property  def context(self):      return self.__context  def add_test(self, test):      self.__tests.append(test)  def run(self):      for test in self.__tests:          test.init()      for test in self.__tests:          test.prepare()      for test in self.__tests:          test.run() 

La belleza del archivo de configuración es que se puede generar en la granja de ensamblaje para diferentes ensamblajes en modo automático. Pero pasar la configuración de todas las pruebas a través de este archivo puede no ser muy conveniente. Para hacer esto, hay un xml de configuración especial que se almacena en el repositorio del proyecto y se escriben en él listas de archivos ignorados, máscaras para buscar en el código, etc.



Además de la parte general, los proyectos tienen sus propias peculiaridades y diferencias; por lo tanto, hay conjuntos de pruebas de proyectos que están conectados al sistema a través de la configuración del corredor. Para el código en los ejemplos, un par de líneas serán suficientes para ejecutar:

 def setup(runner):  runner.add_test(VerifyTexture(runner.context))  runner.add_test(VerifyModels(runner.context)) def run():  raw_config = '''  [main]  app_path = {app_path}  build_type = production  platform = ios  '''  runner = Runner(raw_config, setup)  runner.run() 

Rastrillo recogido

Aunque Python en sí es multiplataforma, regularmente tuvimos problemas con el hecho de que los usuarios tienen su propio entorno único, en el que pueden no tener la versión que esperamos, varias versiones o ningún intérprete. Como resultado, no funciona como esperamos o no funciona en absoluto. Hubo varias iteraciones para resolver este problema:

1. Python y todos los paquetes son instalados por el usuario. Pero hay dos "peros": no todos los usuarios son programadores y la instalación mediante pip install para diseñadores, y también para programadores, puede ser un problema.
2. Hay un script que instala todos los paquetes necesarios. Esto ya es mejor, pero si el usuario tiene instalada la python incorrecta, pueden producirse conflictos en el trabajo.
3. Entregar la versión correcta del intérprete y las dependencias del almacenamiento de artefactos (Nexus) y ejecutar pruebas en un entorno virtual.

Otro problema es el rendimiento. Cuantas más pruebas, más tiempo se verifica el cambio en la computadora del usuario. Cada pocos meses hay un perfil y optimización de cuellos de botella. Por lo tanto, se mejoró el contexto, apareció un caché para archivos de texto, se mejoraron los mecanismos de predicados (determinando que este archivo es interesante para la prueba).

Y luego solo queda resolver el problema de cómo implementar el sistema en todos los proyectos y obligar a todos los desarrolladores a incluir ganchos de segunda mano, pero esta es una historia completamente diferente ...

Conclusión

Durante el proceso de desarrollo, bailamos en el rastrillo, luchamos duro, pero aún así obtuvimos un sistema que nos permite encontrar errores durante la confirmación, redujo el trabajo de los probadores y las tareas antes del lanzamiento sobre la falta de textura eran cosa del pasado. Para una felicidad completa, una configuración simple del entorno y la optimización de las pruebas individuales no son suficientes, pero los golems del departamento de ci trabajan duro en esto.

Puede encontrar un ejemplo completo del código utilizado como ejemplos en el artículo en nuestro repositorio .