Une petite mise à jour du Lexpage aujourd'hui :

- Le rythme de publication des billets ne change pas (s'il y a 8 billets en stock, c'est 2 par jour, sinon 1 seul). Par contre le premier billet du jour sera toujours publié à minuit (alors qu'avant, c'était parfois à 12h), et les éventuels billets ajoutés/supprimés dans le courant de la journée sont pris en compte pour la publication automatique.

- Le bug qui rendait impossible l'upload d'avatar ces 3 derniers jours a été corrigé. Normalement, tout est fonctionnel, au moins pour les avatars en gif, png et jpeg.

- Un icône de login remplacera l'icône de menu lors de la navigation sur petit écran, si le surfeur n'est pas identifié comme utilisateur.

- Mise à jour de la librairie jquery-oembed (même si ça ne résoud pas ce dont on parlait sur le topic à propos de webm et gifv).

Le reste concerne des changements internes (notamment à propos de Markdown) ainsi que des tests supplémentaires (et une vraie configuration de coverage, qui retourne maintenant >80% de coverage au lieu de ~50% comme précédemment, quand il lurkait sur les librairies externes ).

Guybrush(et une vraie configuration de coverage, qui retourne maintenant >80% de coverage au lieu de ~50% comme précédemment, quand il lurkait sur les librairies externes ).

Et avec les nouveaux tests pour les billets, le forum et la messagerie, on est maintenant à 90%. Je pense que je peux raisonnablement changer des choses dans le code sans avoir peur de tout casser et de ne pas m'en apercevoir avant la mise en prod

Le code coverage n'est pas un indice de qualité
Vouloir atteindre 95/100% de code coverage en unit-test est inutile, c'est un joli but qui fait bien dans les statistiques, mais il y a des choses qui sont trop compliqués à tester, même en Mockant comme un fou. C'est pour ça qu'on passe après aux CUIT pour tester le reste.
Mais c'est bien déjà

PetitCalgonLe code coverage n'est pas un indice de qualité

Nop, c'est un indice de résistance au changement et de bonne testabilité du code. Ah ben donc de qualité

PetitCalgonVouloir atteindre 95/100% de code coverage en unit-test est inutile, c'est un joli but qui fait bien dans les statistiques, mais il y a des choses qui sont trop compliqués à tester, même en Mockant comme un fou. C'est pour ça qu'on passe après aux CUIT pour tester le reste.

C'est le cas quand on veut pas refactorer son code pour le rendre testable
Une couche service bien foutue est testable à 100% sans problème.

Les couches de controllers et de repository n'ont effectivement pas d'intérêt en TU, si elles sont bien découplées du métier.
Les tests d'intégrations sont bons pour tester le fonctionnement global d'une IHM ou d'une API, pas pour compenser un manque de TU. Ils ont d'autres inconvénients néanmoins (lents, besoin d'un environnement bien provisionné et "propre" en données).

PetitCalgonLe code coverage n'est pas un indice de qualité

Je sais, et j'en suis convaincu aussi. C'est un indicateur, parmi d'autres, mais avoir 100% (ou même un autre pourcentage) n'est pas suffisant, clairement Surtout que dans le cas présent, la moitié des tests ne fait que simuler un appel à une page, et de vérifier que tout se passe bien. Il y a quelques tests fonctionnels spécifiques, et quelques tests unités (mais essentiellement, la raison derrière ces choix, c'est que Django s'occupe de la partie "bas niveau", je n'ai donc pas besoin de tester cette partie là).

FabeLes couches de controllers et de repository n'ont effectivement pas d'intérêt en TU, si elles sont bien découplées du métier.
Les tests d'intégrations sont bons pour tester le fonctionnement global d'une IHM ou d'une API, pas pour compenser un manque de TU. Ils ont d'autres inconvénients néanmoins (lents, besoin d'un environnement bien provisionné et "propre" en données).

Voilà ce que je voulais résumer avec ma dernière phrase

GuybrushJe sais, et j'en suis convaincu aussi. C'est un indicateur, parmi d'autres

Indeed, c'était ma pensée.
Sinon quand un chef de projet veut avoir un code coverage à 95%, les devs écrivent des TU bateaux rien que pour augmenter le code coverage et qui ne testent au final que rien.
Tester qu'on a une ArgumentNullException quand on lance une méthode avec le paramètre null, généralement, ça n'apporte pas grand chose.

PetitCalgonSinon quand un chef de projet veut avoir un code coverage à 95%, les devs écrivent des TU bateaux rien que pour augmenter le code coverage et qui ne testent au final que rien.Tester qu'on a une ArgumentNullException quand on lance une méthode avec le paramètre null, généralement, ça n'apporte pas grand chose.

Clairement. D'ailleurs, je ne voulais pas tomber dans ce travers. Je me suis servi du coverage pour identifier les parties de code qui n'étaient actuellement pas visitées par un test, et j'ai écrit des tests fonctionnels spécialement pour couvrir ces parties, non pas pour augmenter le score, mais parce que ce sont des aspects importants.

Je vois de nombreux projets où les gens prévoient des règles d'exclusion spécifiques juste pour que certaines lignes ne soient pas prises en compte, et augmenter artificiellement le coverage. En Python, c'est très simple : il suffit d'ajouter un # pragma: no cover pour ignorer un block. Mais c'est "de la triche"..

Petite mise à jour aujourd'hui. Tout d'abord, le menu a été un peu réorganisé. Les changements peuvent ne pas plaire (auquel cas il est possible que je revienne en arrière) mais la subdivision par catégories (plutôt qu'un simple divider horizontal) me semble pertinente. A noter que sur appareil mobile, cette division n'apparait pas (pour ne pas nécessiter un scrolling supplémentaire).

A coté de ça, la recherche a été mise à jour. Rien de folichon, j'ai simplement ajouté la possibilité de rechercher parmi les messages du minichat, parmi les slogans, et le choix par défaut est "Messages des discussions", considérant les réponses fournies sur l'autre topic.

Problème : la home en format "desktop" a souvent un soucis lorsque une série de 3 ou + niouz à "gros" contenu rédactionnel passent en n+3, sur la colonne de droite, quand les niouz' plus récentes sont courtes. ex : http://i.imgur.com/1mzyFM4.png. Ça fait un gros blanc dans la page avant le contenu "forum".

Ce problème est exacerbé par l'effet "vagues", on a souvent une série de niouz par une personne, puis une série par une autre personne, etc, et certains sont plus prolixes que d'autres. Donc ce soucis arrive "souvent".

Solution : au lieu d'une grille découpée en 9-3, on modifie légèrement pour garder cet effet gros pavé de gauche, mais en réduisant à 8-4 (le col-sm-9 du bloc de gauche devient col-sm-8) : ex : http://i.imgur.com/JUIBfLs.png ... ?

Après, bien sûr, dans le cas inverse la col de droite risque d'être vide, mais je trouve ça moins grave que le gros trou blanc visible dans le 1er screen.

Je suis conscient du problème, mais je ne pense pas qu'un 8-4 va régler les choses, juste déplacer probablement le problème, dépendant aussi de la largeur d'écran utilisée. Y a pas une astuce en CSS qui permettrait à la colonne de droite de prendre "au pire" 100% de la hauteur de la colonne de gauche, et de faire un overflow dans le cas où ça dépasse ?

La largeur "desktop" : tous les écrans avec une largeur > à 992px ont le même visuel, et en dessous ce problème n'existe pas (hormis de 991 à 768, mais pas vraiment car le problème n'existe pas avec le minichat qui dégage et donc laisse une tonne de place).

Le calcul de la hauteur des blocs flottants en CSS, oublie, c'est juste impossible, faut user du JS. Un flottant sort du flow, il n'a pas de hauteur pour son parent (d'où le besoin de clear un élément qui suit). Et l'overflow me semble une mauvaise idée. Peut être avec les flexbox, mais c'est pu d'mon age (il fait mal celui-là !).

Ma solution est loin d'être parfaite, je sais bien, je trouve que c'est une amélioration à la marge, sur un phénomène récurrent.