rueil, il y a des chouettes trucs ... mais loin de la gare. La gare est super excentrée en fait

 
Autant les tours c'est marrant, autant la "fontaine" bleu fluo devant

bon, apres, il y a un menu probleme de prix
 
http://www.seloger.com/detail.htm? [...] bclannpg=5

Faire du TDD c'est bien, mais que quand lancer un test prend pas 60 secondes

Faire du TDD c'est bien, mais que quand lancer un test prend pas 60 secondes

On a un test ici il met 26 heures à tourner

 quelque chose me dit que vous ne le faites pas passer avant chaque commit

C'est bizarre, moins y'a de monde mieux je travaille moi...

Deux hommes-lapins, perchés sur un cercueil, pèchent, sans fil, dans une mer de draps blancs où gisent cinq corps gémissant, le tout encerclé de deux douzaines de cranes d'animaux. Le théâtre parfois c'est un peu (c'était Hamlet...)

C'est un des principes du TDD, d'avoir des tests qui tournent rapidement

15 000 kW/h pour une éolienne de 1m60 de diamètre ?
Si c'est vraiment le cas, ça vaut le coup de mettre ça sur le toit de tous les immeubles, non ? Surtout les grandes tours, où c'est pas trop gênant visuellement.

 
On ne fait pas de Hamlet sans casser les yeux. /harko

15000 kW/h  

pourquoi pas des gigowatts aussi?

Cf tests sqlite3, tu peux ne faire tourner qu'un sous-ensemble des tests à chaque commit (genre pas ceux qui prennent 26h). Après, idéalement faut optimiser les tests, mais quand t'as 45 millions de lignes de code et de scripts juste pour tes tests, 1.5Go de données de tests et que tes tests cases sont paramétriques, genre

on peut excuser de pas tout faire tourner à chaque fois

kWh pas kW/h (c'est une energie, pas un accroissement de puissance)

Cf tests sqlite3, tu peux ne faire tourner qu'un sous-ensemble des tests à chaque commit (genre pas ceux qui prennent 26h). Après, idéalement faut optimiser les tests, mais quand t'as 45 millions de lignes de code et de scripts juste pour tes tests, 1.5Go de données de tests et que tes tests cases sont paramétriques, genre

on peut excuser de pas tout faire tourner à chaque fois

Sérieux ??

Cf tests sqlite3, tu peux ne faire tourner qu'un sous-ensemble des tests à chaque commit (genre pas ceux qui prennent 26h). Après, idéalement faut optimiser les tests, mais quand t'as 45 millions de lignes de code et de scripts juste pour tes tests, 1.5Go de données de tests et que tes tests cases sont paramétriques, genre

on peut excuser de pas tout faire tourner à chaque fois

Dans mon cas, j'ai que 61 pauvres tests dans mon "unité", mais c'est la MEP de la bdd à chaque fois qu'est longue, et quand t'es en débuggage c'est chiant
 
C'est ptet en partie de ma faute si c'est si long, je dis pas, je poussais juste un coup de gueule à la base
 
D'ailleurs si des gens ici font des tests avec Symfony+Doctrine, je veux bien des conseils Je compte sur les lurkeurs

http://www.sqlite.org/testing.html

jour ferié roxor, thx zombie jesus

 
On ne fait pas de Hamlet sans casser les yeux. /harko

J'ai 6 personne sur 8 qui ont accepte mon meeting de lundi, dont 5 qui me demandent le numéro d'audio call pr joindre a distance

Sérieux ??

100% de branch coverage, ceci explique cela. Bon c'est tout du code copié-collé, mais quand même.

Dans mon cas, j'ai que 61 pauvres tests dans mon "unité", mais c'est la MEP de la bdd à chaque fois qu'est longue, et quand t'es en débuggage c'est chiant

c'est ce que je te proposes (enfin avec un peu plus de terrain quand même )  
 
en banlieue ouest de mâcon / chalon /louhans

http://www.sqlite.org/testing.html

Dans ce cas lancer les tests de la feature/bug sur lequel tu travailles et lancer les autres tests pendant la nightly?
Avec Django je fais tourner mes tests sur une BDD SQLite en mémoire.
Si t'as possibilté de faire ça....

Tu peux pas utiliser une db in-memory pour aller un peu plus vite? Plutôt que de taper sur le dix en permanence?

 
j'ai habité à 15km de Louhans pendant 4 ans...run, you fools    
 

45 millions de lignes

A tenter ouais, c'est vrai que j'y pense pas souvent. Même si c'est surement l'ORM qui rallentit le plus.
Par contre, ya moyen de sonder ce qui se passe dans cette base, pour débugger ?

 
A tenter ouais, c'est vrai que j'y pense pas souvent. Même si c'est surement l'ORM qui rallentit le plus.
Par contre, ya moyen de sonder ce qui se passe dans cette base, pour débugger ?

 
Sinon, ça existe pas un replayer de requètes ?
 
(Tu démarre avec un snapshot de l'état initial de la db, si y'a une requète de lecture, tu la demande à la vrai base et t'enregistre la réponse dans un cache associé à ton état en cours, si y'a une requète de modification tu balance à la db, tu crée un lien taggé avec la requète de l'état initial vers un nouvel état avec son propre cache et ton état en cours devient ce nouvel état, Tu sauvegarde tout ça quand t'as finit tout ton scénario. Quand tu replay, tu parcours le graph à partir du noeud initial et tu navigue à chaque requète de modification pour être dans le bon cache, tu réponds avec ce qu'il y a dans le cache en cours à chaque requète de lecture. Et t'as même le droit de stocker plusieurs scénarios dans le même graphe de caches ils seront cohérents, tu peux démarrer à partir d'un noeud autre que le noeud de départ, etc...)