\item Comment roches et sols engegistrent les perturbations physico-chimique naturelles ou anthropique de leur environement? Quelles sont les mécanismes qui gouvernent la croissance, la sorption et l’alteration des minéreaux? Comment les processus hydrothermaux et magnétiques concernent-ils les ressources minérales? Comment produire de l’hydrogène? La carbonation minéral, une voie pour le stockage du CO2?
\end{enumerate}
\newpage{}
\section{Présetation du stage}
\subsection{Gestion de projet}
\subsubsection{Ce qui était prévu / Ce que j'ai fait}
\begin{figure}[H]
\caption{Prévision et réalisation du travail}
\includegraphics[width=\textwidth]{GANTT}
\end{figure}
\subsubsection{Ce que j'ai fait}
\paragraph{}
Sachant que j'étais sur un projet seule, le besoin de planification ne c'est pas fait ressentir. En effet, ce genre de methode est très utils dans les projet de groupes ou les acteur\textperiodcentered ice\textperiodcentered s on besoin de communiquer leur avancées ainsi que le plans d'acction. Ainsi, je n'ai pas réalisé de diagrame de GANTT et c'est seuelement à posteriori que j'en ai constuit un (cf. Figure \ref{fig:GANTT}). Cepandant, j'ai quand même organiser mon travail en différentes tâches qui respecte un certain patern. En effet, pour chaque web services, je faisait une tache \textit{Scénario} et une tâche \textit{Implémentation}. Chaqu'une de ces tâches était elle même divisé en sous tâches. Par exemple, la tache \textit{Station Implementation} avait une sous-tâche nomé \textit{given the paramerter value from start to end on the level level [STATION]} ou encore \textit{Make xml vlaidator compute str and not etree}.
\begin{figure}[H]
\label{fig:GANTT}
\caption{Réalisation du travail}
\includegraphics[width=\textwidth]{GANTT}
\end{figure}
\paragraph{}
Pour organiser ces tâches, j'ai utiliser les \textit{issues} de \textit{gitlab} (cf. chap.~\ref{chap:gitlab}). En effet, les supper tâches étaient modélisées par des \textit{labels} combinable. Par exemple, pour la tâche \textit{scenario Dataselect}, les labels étaient \textit{Scénario} et \textit{WS-Dataselect} (cf. Figure~\ref{fig:task}).
\begin{figure}[H]
\caption{Exemple de tâche}
\centering
\includegraphics[scale=0.5, frame]{taskGitlab}
\label{fig:task}
\end{figure}
\subsubsection{L'organisation de l'équipe}
\paragraph{}
La manière dont l'équipe s'organisait était structuré de la sorte:
@ -163,6 +176,7 @@
\label{fig:gitflow}
\end{figure}
\subsubsection{Gitlab}
\label{chap:gitlab}
\paragraph{}
Gitlab est un logiciel de type serveur permetant de stoquer un dêpot git et de le redistrubuer ensuite. Il permet la centralisation du code ce qui aboutil à une collaboration plus éfficace. En effet, Ce qu'apport gitlab par rapport à un simple serveur de partage de fichiers comme \textit{nfs} ou \textit{ftp}, c'est de pouvoir avoir une version sur sa propre machine, coder sur cette verssion local et soumettre ces moddification au dêpot distant (gitlab) avec une gestion intéligente des conflits (quand plusieurs personnes modifie un même fichier au même endoit).
\paragraph{}
@ -217,7 +231,7 @@
\paragraph{}
Le web service \textit{\href{https://ws.resif.fr/fdsnws/station/1}{station}} permet de récuperer les méta données des stations de mesure. C'est à dire, leur nom, leurs positions, les cannaux disponible, etcetera. Bien qu'il soit possible de récuperer ces méta données sous forme de text, le principal format pour ce genre de requette est le StationXML, un dérivé du XML. Ce format permet un traitement numerique plus facile ainsi qu'une plus grande capacité à contenir des informations qu'un format texte habituel. Voici deux exemples de requettes, \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&cha=HHZ&level=channel&format=xml}{une sous le format XML} et \href{https://ws.resif.fr/fdsnws/station/1/query?net=FR&sta=CFF&cha=HHZ&level=channel&format=text}{la meme requete sous le format text} (lien cliquable).
\begin{figure}[H]
\caption{Exemple d'une requete \textit{station} demandant du StationXLM pour la station FR.CFF }
\caption{Exemple d'une requete \textit{station} demandant du StationXML pour la station FR.CFF }
Pour chaque \textit{step}, \textit{behave} ira chercher et executer la bonne fonction grâce au préfix \textit{@given}, \textit{@when} et \textit{@then}. Ainsi, le nom de la fonction n'est pas imprtant pour \textit{behave}. Les variables peuvent être transmises de fonction en fonction grâce à la notion de \textit{context}. Concrétement, c'est un objet qui est passé en paramètre de chaque fonction est qui est capable de stocker des variables sous la forme de propriété.
\subsection{Environement}
\textit{Behave} est capable de généré un environement entre chaqu'un des \textit{items} composant les tests (\textit{feature}, \textit{scénario}, \textit{tag}, ...). Pour ça, il faut définir des fonctions avec des noms prédéfinit par \textit{behave} dans un fichier nomé \textit{environment.py}.
\subsubsection{Environement behave}
\textit{Behave} est capable de généré un environement entre chaqu'un des \textit{items} composant les tests (\textit{feature}, \textit{scénario}, \textit{tag}, \dots). Pour ça, il faut définir des fonctions avec des noms prédéfinit par \textit{behave} dans un fichier nomé \textit{environment.py}.
\paragraph{}
Les noms des fonctions sont composés de la manière suivante: $<$before|after$>$\_$<$\textit{element}$>$ (exemple: before\_feature, after\_scenario, before\_all, \dots). J'ai pu me servir de certaine de ces fonction, notament pour la configuration des tests par des élément extenes tel que des variables d'environement ou des fichiers de configuration. Ainsi, avant tout, je configure le protocole utilisé (http ou https) et le couple loggin/mo de passe pour l'accès aux données réstraintes. Avant chaque \textit{feature}, je séléction le \textit{web service} addéquat.
Les noms des fonctions sont composés de la manière suivante: $<$before/after$>$\_$<$\textit{element}$>$ (exemple: before\_feature, after\_scenario, before\_all, \dots). J'ai pu me servir de certaine de ces fonction, notament pour la configuration des tests par des élément extenes tel que des variables d'environement ou des fichiers de configuration. Ainsi, avant tout, je configure le protocole utilisé (http ou https) et le couple loggin/mot de passe pour l'accès aux données réstraintes. Avant chaque \textit{feature}, je séléction le \textit{web service} addéquat.
\subsubsection{Configuration par l'environement}
\paragraph{}
Pour plus de souplesse à l'utilisation, j'ai fait en sorte que les tests soit configurable sans que le code source soit modifié. En effet, il existe plusieurs contexte de déploiment pour les différent: le contexte de production, celui de développement et celui de stage. Chaque contexte a son utilité et sont accèssible par des nom de domaine (début de l'URL) différents. Ainsi, pour définir le contexte depuis l'exterieur du programe, il suffit de définire la vairable d'environement \textit{BEHAVE\_TEST\_CONTEXT} avec les valeur \textit{PROD}, \textit{DEV} ou \textit{STAGING}.
\paragraph{}
Les URL sont ensuite récupéré depuis un fichier de configuration au format YAML. Ces URL contiènent à la fois le contexte (ws.resif.fr, ws-dev.resif.fr et ws-staging.resif.fr) ainsi que le chemain vers chaque \textit{web service}. En effet, celui-ci est variable en fonction du context. Par exemple pour ph5-availability, les URL sont: \textit{ph5ws.resif.fr/resifws/availability/1/query}, \textit{ws-dev.resif.fr/resifws/ph5-availability/1/query} et \textit{ph5ws-staging.resif.fr/resifws/availability/1/query}. La hiérarchie des informations du fichier fait qu'il est facile de modifier ou ajouter des URL. En effet, le premier niveau de hierarchisaion est le nom du \textit{web service} et le deuxième, le nom du contexte (cf. Figure~\ref{fig:yamlOK}). C'est ici que ce situe l'URL. Ainsi, pour ajouter un \textit{web service} dans la configuration, il sufit d'ajouter son nom et de décrire chaque contexte. Si cette hierarchie était inverssée (cf Figure~\ref{fig:yamlKO}), il serait plus compliquer de retrouver les information. Imaginon que je veuille modifier les URL \textit{web service} \textit{station}. Pour ca, il faudrai que je prène chaque contexte et que je trouve parmis tous les \textit{web services} le bon, le modifier et répéter l'oppération attant de fois qu'il y a de contexte.
\paragraph{}
Ainsi, j'ai pu faire en sorte que la configurtion des texts soit maximale grâce au variables d'environements. En effet, il y a quatres variables d'environemnts avec les quelles il est possible de spécialiser les tests:
\begin{itemize}
\item \textbf{BEHAVE\_TEST\_PROTOCOLE}: pour définir le protocole utilisé: http ou https (https par défaut)
\item \textbf{BEHAVE\_TEST\_CONTEXT}: pour définir le contexte (PROD par défaut)
\item \textbf{BEHAVE\_TEST\_LOGGIN}: pour définir l'utilisateur\textperiodcentered ice et ainsi garentir le respect des droit vis à vis de la visibilité des données (rien par defaut)
\item \textbf{BEHAVE\_TEST\_PASSWORD}: pour authentifier l'utilisateur\textperiodcentered ice (rien par défaut)
\end{itemize}
\begin{figure}[H]
\caption{Éxtrai du fichier de configuration des contextes}
Lors de la réalisation des tests du deuxième web service, \textit{availability}, je commençais à reprendre des fonctionalités du premier, \textit{station}, comme l'envoi de requette au web service, la verification de format de la réponse. À ce moment là, j'ai resenti le besoin de metre en commun certaine partie de code et d'en spécialiser d'autres. Ainsi, j'ai commancé un travail de factorisation de code.
\subsubsection{Démarche}
\paragraph{}
Pour implémenter les \textit{steps}, ma démarche était empirique. C'est à dire que je l'implémentais, vérifiais son comportement et l'amélorais en suite. Ainsi, j'étais dans l'espris de la methode \textit{agile}. En effet, avec les ticket gitlab, je pouvais facilement avoir une tache pour reprendre un code précédament écris.
\subsubsection{Factorisation de code}
\paragraph{}
C'est dans cet espris que lors de la réalisation des tests du deuxième web service, \textit{availability}, je commençais à reprendre des fonctionalités du premier, \textit{station}, comme l'envoi de requete au web service ou la verification de format de la réponse. À ce moment là, j'ai resenti le besoin de metre en commun certaines parties de code et d'en spécialiser d'autres. Ainsi, j'ai commancé un travail de refactorisation de code qui a depuis toujours était présent jusqu'a la fin de mon stage.
\paragraph{}
En effet, dupliquer du code, c'est pouvoir introuduire le même bug à plusieurs endrois différents ou bien même une impossibilité de reprendre le code par une autre personne car ce genre de code est assez difficile à lire et comprndre. Refactoriser le code permet donc une meilleurre stabilité ainsi qu'une plus grand facilité à le corriger.
\paragraph{}
Pour éviter de dupliquer du code, j'ai dût créer differents objets ayant diférrants types de relations entre eux (association dirigée, héritage, \dots). Une des difficutltés non négligable est qu'en python, le principe de classe abstraite n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de Query. En effet, le comportement des sous classes dépendait de plusieurs parametres: la methode HTTP et le webservice intérogé. Ainsi, un objet Query n'a pas de sens si is est instancié.
Pour éviter de dupliquer du code, j'ai dût créer differentes classes ayant diférrants types de relations entre elles (association dirigée, héritage, \dots). Une des difficutltés non négligable est qu'en python, le principe de classe abstraite ou d'interface n'éxiste pas. Cela m'a notament posé problème lors de l'implémentation des sous classes de Query. En effet, le comportement des sous classes dépendait de plusieurs parametres: la methode HTTP (GET ou POST) et le \textit{webservice} intérogé. Ainsi, un objet Query n'a pas de sens si is est instancié.
\paragraph{}
Pour palier a ce problème, j'ai simuler le comportement d'une classe abstraite grace à la valeur \textit{NotImplemeted}. Cette valeur est retourné à chaque fois qu'une methode censé être abstraite est appeler. Toute fois, je n'ai pas interdit l'instentiation de ces objet car cela complexifirai le code juste pour introduire une notion étrangère à python. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilités (Query, Response, Validator, \dots), ce qui permetra une maintnabilité plus simple pour les développeur\textperiodcentered euse\textperiodcentered s qui seront sucéptible de reprendre mon code. Ainsi, pour permetre au modele de pouvoir tester de nouveau web services, il sufit de créer une nouvelle classe qui hérite de Query et une nouvelle classe qui hérite de Response et implementer les methodes \textit{abstraites} (cf. Fig~\ref{fig:QueryClassDiag}, Fig~\ref{fig:ResponseClassDiag}).
Le fait d'avoir des classes abstraites ou des interfaces permet aussi de créer ce qu'on appelle des points d'extentions. Un point d'extention, c'est une entitée qui permet de garentir des fonctionalitées lors ce qu'une classe hérite de cette entité. Par exemple, si j'hérite d'une interface \textit{Conteneur}, des classes qui l'implémentent comme \textit{Liste}, \textit{Fille} ou \textit{Queue} sont obligées de contenir des données. Ainsi, la personne qui utilise ces classes n'a pas à ce demander si elle peut contenir des données.
\paragraph{}
Pour palier a ce problème, j'ai simuler le comportement d'une classe abstraite grace à la valeur \textit{NotImplemeted}. Cette valeur est retourné à chaque fois qu'une methode censé être abstraite est appeler. Toute fois, je n'ai pas interdit l'instentiation de ces objet car cela complexifirai le code juste pour introduire une notion étrangère à python. Ainsi, j'ai pu obtenir plusieurs points d'extensiblilités (Query, Response, Validator, \dots), ce qui permetra une maintnabilité plus simple pour les développeur\textperiodcentered euse\textperiodcentered s qui seront sucéptible de reprendre mon code. Ainsi, pour permetre au modele de pouvoir tester de nouveau web services, il sufit de créer une nouvelle classe qui hérite de Query et une nouvelle classe qui hérite de Response et implementer les methodes \textit{abstraites} (cf. Figure~\ref{fig:QueryClassDiag}, Figure~\ref{fig:ResponseClassDiag}).
\subsubsection{Description du modele de classes}
\paragraph{}
Dans mon modele de classes, j'ai pu faire un point d'entrée qui permet un simple utilisiation depuis l'éxterieur, dans mon cas, depuis les tests behave. En effet, la classe \textit{QeryGenerator} agit comme une \textit{factory}, c'est à dire, une classe qui permet de créer d'autre types de classes en foction de divers parametres. Par exemple ici, \textit{QueryGenerator} vas créer des classes filles de \textit{Query} en fonction du web service que l'on veut requeter. En effet, une requette, modéliser par la classe \textit{Query} doit être spécialisée en fonction du web service intérogé (cf. Figure~\ref{fig:QueryClassDiag}). Une fois que le web service en question est intérogé, la classe \textit{Query} se créer une \textit{Response}, elle aussi spécialisée en fonction du web service intérogé mais aussi en fonction du format attendu (cf. Figure~\ref{fig:ResponseClassDiag}). Aussi, chaque \textit{Response} doit pouvoir verifier que son contenu coresponde au format attendu. Ainsi, chaque \textit{Response} utilise un \textit{Validator} spécialisé a cet effet(cf. Figure~\ref{fig:ValidatorClassDiag}).
\begin{figure}[h]
Dans mon modele de classes, j'ai pu faire un point d'entrée qui permet un simple utilisiation depuis l'éxterieur, dans mon cas, depuis les tests \textit{behave}. En effet, la classe \textit{QeryGenerator} agit comme une \textit{factory}, c'est à dire, une classe qui permet de créer d'autre types de classes en foction de divers parametres. Par exemple ici, \textit{QueryGenerator} vas créer des classes filles de \textit{Query} en fonction du web service que l'on veut interoger grâce à une methode nommé \textit{generateQuery}.
\paragraph{}
La classe \textit{Query} modélise une requete à passer ou passée à un \textit{web service}. Une \textit{Query} est cappable de construire la requette en fonction de la méthode d'interogation (GET ou POST). Une fois que les requette était construites, il était possible d'intéroger d'intéroger le serveur dont l'URL et les arguments sont attributs de \textit{Query}(cf. Figure~\ref{fig:ValidatorClassDiag}).
\paragraph{}
Cependant, une requete doit être spécialisée en fonction du web service intérogé (cf. Figure~\ref{fig:QueryClassDiag}). Cela permet de spécialiser le comportement de la réponse lors de sa création dans la méthode \textit{buildResponse}. Par exemple, pour le \textit{web service} \textit{station}, il a falu créer une classe \textit{StationQuery} qui implémente la méthode abstraite de \textit{Query} nomé \textit{buildResponse} qui est appeler lors ce qu'on intréroge le \textit{web service} et que l'on a une réponse. La structure de ce genre de méthode est décrite sur la Figure~\ref{fig:buildResponse}.
\caption{Diagramme de classe pour les classes Query}
\includegraphics[width=\textwidth]{query}
\label{fig:QueryClassDiag}
\end{figure}
\paragraph{}
La classe \textit{Response} est aussi un point d'éxtensibilité qui garentie qu'une réponse sait dire si sont contenu est bien formaté. Les classes qui hérite diréctement de \textit{Response} sont aussi des classes abstraites. Elle permette de spécialiser le comportement des classes filles en fonction des \textit{web services} intérogés. Par exemple, il existe une classe abstraite \textit{ResponseAvailability}. C'est à l'étage du dessous que sont implémentées les classes concraites qui permette de traiter un format (par exemple la classe \textit{ResponseDataselectMiniSeed}). Ce découpage est ainsi fait car deux \textit{web services} peuvent renvoyer un même format mais avec un contenu complétement différant. Par exemple, \textit{availability} peut renvoyer des valeurs au format \textit{text} (les valeurs son séparé par des espaces) ainsi que \textit{station} (les valeurs sont séparées par un pipe) (cf. Figure~\ref{fig:respAvaText}, Figure \ref{fig:respStaText}). Ainsi, le traitement de la réponse est différente et c'est pour répondre à cette contraint que j'ai dût faire une si grosse arboréssance(cf. Figure~\ref{fig:ResponseClassDiag}).
\begin{figure}[H]
\caption{Extrait de réponse au format \textit{text} de \textit{availability}}
Dans le paragraph précédant, j'ai dit qu'un objet \textit{Response} devait être capable de vérifier si le format de son contenu était correcte sans en expliquer les détails. C'est ce que vais donc faire ici. Pour pouvoir faire ça, la classe \textit{Response} doit utiliser un \textit{Validator}. C'est une classe qui permet de dire une condition complexe est réspécté. Il existe deux sortes de validateurs pour le moment: les \textit{HTTPValidator} et les \textit{FormatValidator}. Ici ce sont des \textit{FormatValidator} qui sont utilisés par les objets \textit{Response}. Chaque format possède sa manière d'être verifié. Par exemple, pour un format CSV, il faut verifier que chaque ligne correspond au parern valeur séparateur grâce à une expression régulière. J'avais essayer de faire cette verification avec la bibliothèque CSV mais l'objet qui permet de lire un CSV ne lève pas d'erreur lors ce que le contenu n'est pas bien formaté. Pour continuer l'exemple, le format \textit{MiniSEED}, la bibliothèque \textit{obspy} qui permet de lire ce format. Ainsi, si l'objet qui lit le contenu lève une erreur lors de la lecture du contenu, c'est qu'il est mal formaté. Cepandant, il y a des formats particulier comme le format ZIP qui en fait contien un fichier CSV à l'interieur. C'est pour ça que je l'ai fait hérité de CSV. Ansi, la méthode \textit{validate} de \textit{ZipValidator} extrait le fichier CSV à l'interieur et appelle ensuite la même méthode de son parent avec le contenu du fichier(cf. Figure~\ref{fig:ValidatorClassDiag}).
\begin{figure}[H]
\caption{Diagramme de classe pour les classes Validator}
\includegraphics[scale=0.5]{validator}
\label{fig:ValidatorClassDiag}
\end{figure}
\subsubsection{Transmition du savoir}
\paragraph{Documentation de ma production}
Pour pouvoir avoir une vision globale du projet ainsi que pour la transmission de ma production, j'ai du la documenter. Pour cela, j'ai utiliser plusieurs outils. Tout d'abord, pour avoir une documentation de mon code en lui même, éxpliquer le rôle de chaque classe, chaque methode, j'ai utiliser l'outil pydoc, qui permet de generer une documentation HTML en lisant les \textit{docstings} de mon code. Une \textit{docstring} est espece de paragraph, placé en haut de l'item à documenter (classe, methode, \dots) expliquant l'utilité et le fonctionement de ce dérnier. Cependant, je n'ai pas commencer à documenter mon code dès le début de sa production, donc j'ai donc pris une journée pour l'écrire, à la fin de l'implémentation des tests sur le deuxieme web service que j'ai traiter, c'est à dire, vers le début du moi de mai.
\subparagraph{}
Pour donner une explication sur les relations entres les classes, j'ai réaliser plusieurs diagrames de classes avec l'outil \textit{plantuml}. Cette outil permet de generer un diagrame UML à partir d'un fichier texte formaté qui explique les relations entre classes. L'avantage d'un tel outil est qu'il est facile à versioner par rapport à un fichier binnaire. J'ai comencé la réalisation du fichier plantuml dès que j'ai eu plus d'une classe à implémenter. \textbf{AJOUTER UN BOUT DE .PLANTUML}
Pour donner une explication sur les relations entres les classes, j'ai réaliser plusieurs diagrames de classes avec l'outil \textit{plantuml}. Cette outil permet de generer un diagrame UML à partir d'un fichier texte formaté qui décris les relations entre classes (cf. Figure~\ref{fig:plantuml}). L'avantage d'un tel outil est qu'il est facile à versioner par rapport à un fichier binnaire. En effet, si il y a un conlit entre deux verssions du dépot, il sera difficile à résoudre si c'est un fichier binnaire car illisible. Pour résoudre un conflit, il faut fusioner à la main le contenu des fichier. J'ai donc commancé la réalisation du fichier plantuml dès que j'ai eu plus d'une classe à implémenter.
\begin{figure}[H]
\caption{Extrai de fichier plantuml}
\begin{verbatim}
abstract class Query {
buildGetUrl()
{abstract} buildResponse(response)
refreshCache
response
pstBody
}
class AvailabilityQuery { buildResponse(response) }
class StationQuery {buildResponse(response) }
class DataselectQuery { buildResponse(response) }
class DataselectPh5Query { buildResponse(response) }
Query -> Response
Query <|-- StationQuery
Query <|-- AvailabilityQuery
Query <|-- DataselectQuery
Query <|-- DataselectPh5Query
\end{verbatim}
\label{fig:plantuml}
\end{figure}
\paragraph{Réunions}
En mi chemain de mon stage, j'ai réaliser une présentation de mon travail dans le cadre d'une transmition de savoir au reste de l'équipe. Suite à cela, il y eu de nouveaux échanges et cela à permis d'enrichir le contenu de mes tests. En effet, cette échange à permis de déffinir un plan d'acction pour les semaines qui suivit ainsi que mettre en lumière de nouveau scénario tel que la cohérance des web services entres eux.
\subsubsection{Problèmes rencontrés}
@ -371,7 +533,27 @@
\end{figure}
\subsection{Au delà du stage}
\paragraph{}
Tout au long de mon stage, je devais avoir à l'espris que mon code sera repris et que le logiciel produit devra être utiliser le plus simplement possible. Ainsi, J'ai pu pensé à des amélioration tel que la mise en cache de certaines requettes pour accélérer les test, l'écriture d'un script qui permet de simplifier le lancement des tests, un model de classes qui permet une genericité maxiamle. Certaines de ces idées ont dût être écartées par manque de temps et du fait de le trop grand complexité par rapport au contexte. C'est donc un piste pour continuer l'implémentation des tests.
Tout au long de mon stage, je devais avoir à l'espris que mon code sera repris et que le logiciel produit devra être utiliser le plus simplement possible.
\paragraph{}
Ainsi, J'ai pu pensé à des amélioration tel que la mise en cache de certaines requettes pour accélérer les test, l'écriture d'un script qui permet de simplifier le lancement des tests, un model de classes qui permet une genericité maxiamle. Certaines de ces idées ont dût être écartées par manque de temps et du fait de le trop grand complexité par rapport au contexte. C'est donc un piste pour continuer l'implémentation des tests.
\paragraph{}
J'ai donc réalisé une documentation sur l'utilisation de ma production. Pour qu'elle soit facilement accéssible et lisible, je l'ai faite en \textit{markdown}, un langage de mise en forme de texte, et l'ai mise dans le fichier \textit{REEDME.md}. Ce fichier est affiché automatiquement par gitlab dans l'onglet \textit{Files} (cf. Figure\ref{fig:reedme}).
Pour que l'utilisateur\textperiodcentered ice des tests puissent facilement voir ce qui ce passe lors ce qu'un test échou, j'ai travaillé la sortie standard (cf. Figure~\ref{fig:behaveKO}) des ces dérniers (grossièrement ce qu'ils écrivent sur la console). En effet, le comportement de \textit{behave} est d'afficher les éléments que j'écris dans la sortie standard seuelement si un \textit{step} échoue. Ainsi, j'ai détailler à chaque requete éffécuée, l'URL (pour GET) et le corps de cette requete (pour POST) pour pouvoir la reproduir en dehors de mes tests. J'affiche aussi le loggin utiliser si il a été configuré. Aussi, en fonction des \textit{steps} efféctué, il peut y avoir des sorties différentes. Par exemple, pour le step \textit{Then the HTTP code returned must be 'code'}, le code d'erreur est écris dans la sortie standard.
A diverses ocasions j'ai pu participer a des acctivitées organiser avec l'équipe RÉSIF-DC. Ainsi, j'ai pu acister à un \textit{comtec}. C'est une réunion .
\newpage{}
\section{Bilan}
\paragraph{}
À la fin de mon stage, j'ai pu réaliser toute une panoplie de tests sur six web services differents:
@ -386,12 +568,14 @@
\paragraph{}
J'ai donc pu relever plusieurs bugs, par exemple, une divergence dans le comportement du web service \textit{station} en fonction de la methode utilisée (GET et POST) si on demende une date à la limite éxterieur de ce qui existe (par exemple le 21 novembre 2020 à 12h\textit{60}). Ainsi le travail que j'ai produit à pu servir à mettre en lumière des problèmes qui n'ont pas étés repéré jusqu'à présent. Aussi, dans le cadre d'une réecriture d'un web service, mes test permettent de verifier qu'il n'y a pas eu de régression par rapport à l'implémentation précédente. Ces tests peuvent aussi être lancer de manière automatique dans le cadre d'une verification routinière du bon fonctionement des web services. J'ai aussi documenter mon code pour une transmition du savoir plus facile.
\newpage{}
\section{Lexique}
\begin{itemize}
\item Test de comportement (behavior test) : Test informatique permetant de vérifier le comportement du logiciel testé sur la base de différntes scénario
\item Test de comportement (behavior test) : Test informatique permetant de vérifier le comportement du logiciel testé sur la base de différnts scénarios
\item Nœud A: Équipe de sismologue charcher de placer des sondes, de récolter les données et métadonnées, et de les transmetre au nœud B
\item Nœud B: Équipe de sysmologue charger de traiter les données et métadonnées récolté par les differents nœud A pour coriger les données.
\end{itemize}
\newpage{}
\section{Anex}
\begin{figure}[h]
\caption{exemple de scénario}
@ -411,11 +595,6 @@
Then the HTTP code returned must be '400'
\end{verbatim}
\end{figure}
\begin{figure}[h]
\caption{Diagramme de classe pour les classes Validator}
\includegraphics[width=\textwidth]{validator}
\label{fig:ValidatorClassDiag}
\end{figure}
\begin{figure}[h]
\caption{Diagramme de classe pour les classes Response}
Érina Point
3 years ago
