Reprise du message précédent :

pourquoi, tu voulais passer direct en prod?

Ou mieux, une réfence à la fonction?

 
c'est a dire ?

nan, j'ai déja un test et un prod, mais le prod est buggé (la partie publique pour être exact)

car jamais testé sérieusement.

Ben en javascript les fonctions sont des objets, comme des strings, des entiers, des arrays ou n'importe quoi d'autre

c'est pareil nan ? passer l'objet fonction quoi ?
 

Une fonction est un objet. Après je sais pas comment cibler une fonction écrite "en dur" mais c'est sûrement possible.

Ben non mais la question c'est surtout pourquoi ne pas passer en test, 2 jours avant la mise en prod, alors que le test c'est justement fait pour tester avant la mise en prod, je pense

Parce que je teste autant que je peux (ou presque) en test avant de mettre en prod, mais sur la masse ya des trucs que j'oublie de tester (manque de méthodo ?), et à force ça s'empile.

 
Soit :  

var foo = function(fun) {
    if(getStuff() == true) {
 
    return fun.bind(someOtherStuff);
}

 
Pour moi passer la fonction c'est ça :

foo(function() { return bar})

 
Et passer une réference c'est ça :

function baz() {
      return bar
}
 
foo(baz)

Et donc?

var foo = function(fun) {
    if(getStuff() == true) {
 
    return fun.bind(someOtherStuff);
}

foo(function() { return bar})

function baz() {
      return bar
}
 
foo(baz)

Ben t'as tord, dans les deux cas tu passes une référence à la fonction, c'est juste que dans un cas la fonction est nommée et dans l'autre elle l'est pas

Ouais, j'ma mal exprimé    
 
Tiens, on dirait que j'viens d'écrire un décorator

Et ben ouais c'est comme ça

En gros, ton problème c'est que t'es censé avoir tout testé et que le serveur de test n'est censé être là que pour trouver les derniers petits bugs alors que tu penses en avoir laissé passer plein.
Du coup, là où ton patron pense que c'est faisable en 2 jours, toi t'aurais voulut avoir 15 jours de test pour que les autres te disent ce que t'as loupé.
 
J'ai bon?

torttttttttttttttttttttttttttttttttt

C'est quoi ta méthodologie pour tester ?

et qu'est-ce qui justifie la non-installation d'une version qui a au moins mysqli?

C'est un peu de ma faute. A l'époque où on a pris un dédié, fallait que ça marche tout de suite. Pas le temps de s'amuser à devoir tout configurer. Du coup on a pris un dédié OVH avec le webmin, où tout est fait.
 
Problème, c'est que les mises à jour sont refilées par OVH, et c'est assez sensible aux modifications. Donc recompiler un PHP avec mysqli risque de foirer les mises à jour... Ce qui voudrait dire devoir tout faire à la main, ce qui dépasse mon domaine actuel de compétences.
 
J'ai absolument pas le temps pour l'instant de faire mumuse avec linux. On verra plus tard lorsque ce sera vraiment nécessaire.

le client: "On a déjà une application en php/mysql vous aurez cas la mettre sur le même serveur!"
nous: "Euh ... c'est du php4/mysql3 ... ça va pas le faire"
le client: "pas question qu'on rachète un autre serveur, pas question de mettre a jour celui-là, l'ancienne application ne marcherait plus"
nous: "Bon ok mais il va falloir qu'on fasse des modifs ( dont le coût final approchera 10 serveurs)".
 
Ce genre de cas j'imagine

Oui et non, mon patron ne connait strictement rien aux sites internet, et ça fait 2 semaines qu'il repousse au lendemain.

Oui c'est cencé être les derniers ptis bugs, mais j'avais pas grande idée de leur nombre. A vrai dire ils sont p-e pas aussi nombreux que je pensais ya 30 min, menfin yen a des gros.

J'en ai pas
Et à vrai dire j'ai pas le recul pour dire si les bugs là c'est des effets de bords, ou des conséquences de trucs ouvertement non testés (j'ai eu le droit de tester le paiement hier seulement, "pour qu'on fasse tt en mm tps", alors que je le réclamais pendant 2 semaines, et je zappe un peu trop facilement IE, là c'est ma faute)

Ah ouais quand-même...

Ca vous couterait moins cher de prendre un nouveau dédié, d'installer correctement et de basculer de l'un à l'autre que ce que coute ton temps de développement pour rajouter ce qui manque.

C'est prévu pour 2008. On aura sûrement besoin d'un autre serveur. Cette fois-ci, j'en prendrais un un peu plus "brut", et ferai tout à la patte A l'époque, ça ne se justifiait pas trop.  
 
Et surtout, je pensais qu'OVH allait faire des mises-à-jour plus souvent. A un moment ils avaient un patch pour upgrader en PHP 5.2, avec les PDO et tout, mais ils l'ont retiré, et depuis plus rien. Ca fait plus d'un an maintenant

Stadire ?

Vous avez des méthodos précises de tests ?

 
pourquoi tu les relances pas? Doit bien y avoir moyen d'avoir au moins un php 5.1...

Nous on a enfin passé un serveur en Php5/MySQL5 \o/ (bon il en reste encore 2 en Php4/MySQL3 mais bon ... c'est un début )

La discussion que j'ai déclenchée page précédente sur le PHP, c'est d'un autre monde pour moi

Si j'ai bien compris, quand tu testes ton appli, tu testes à la patte comme ça ?
 
Parce que la première chose à faire, c'est de s'intéresser à Selenium, qui te permet d'automatiser des tests, quelque soit le navigateur. Après côté serveur, quelquesoit la technologie choisie, t'aura toujours un framework de test unitaires pour ton langage.

Y'a qu'à voir sur leur forum, au moins une fois par mois t'as un gars qui demande comment on passe en 5.2, mais sans réponse. Heureusement quand on l'a acheté, il était d'office en 5.1.4, alors c'est pas trop pire. Maintenant un tas d'options étaient désactivées (mysqli, PDO, etc.)

J'ai du mal à voir comment ça marche des "tests automatisés" ?

ouaip, faudrait que je fouilles ces trucs-là... Les tests unitaires ça fait 2 semaines que je sais en quoi ça consiste

Ca, c'est le genre de truc que j'ai toujours trouvé débile et qui m'a fait raller les rares fois où j'y ai eu droit. C'est le meilleur moyen pour ne pas trouver d'où viennent les bugs.
 

Faudrait que je m'y mette moi aussi aux test unitaires un de ces jours. Ca fait un bon moment que je sais ce que c'est mais j'ai jamais pris le temps d'en mettre en place.

Ptain mais je butte sur un truc tout con et je trouve rien sur le forum de Moutouls :
Comment on fait pour cibler un champ d'un formulaire par son name ?
$('superform').champ.value ne fonctionne pas sur IE...

edit : je retire, ça marche.

J'ai un bind de selenium pour PHPUnit. Genre tu veux tester un formulaire de login. Remplir les champs, cliquer sur "ok", et vérifier que t'attéris sur ta page de compte :

$this->open('http://localhost/pouet/login.html');
 
$this->type('userid', 'user1');
$this->type('userpass', 'passe1');
$this->click('//form[@id="loginForm"]//input[@type="submit"]');
$this->waitForPageToLoad(10000);
 
$this->assertEquals('http://localhost/pouet/compte.html', $this->getLocation());

Et ça peut le faire pour FF, IE, ou tout ce que tu veux. T'as pas obligé de passer par php, selenium a tout ce qu'il faut pour le faire tout seul, juste en javascript.

 
ok bon désolé, mais j'ai du mal..
 
en gros dans mon html j'ai un apelle de fonction comme ca :
<a onclick="Cart.updateQty(x,y,'up')">blabla</a>
ou
<a onclick="Cart.updateQty(x,y,'down')">blabla</a>
 
et dans ma classe JS:

 
comment executer ma fonction dans ce cas? je prend le parametre myFonction et je rajoute 2 parentheses ?

$this->open('http://localhost/pouet/login.html');
 
$this->type('userid', 'user1');
$this->type('userpass', 'passe1');
$this->click('//form[@id="loginForm"]//input[@type="submit"]');
$this->waitForPageToLoad(10000);
 
$this->assertEquals('http://localhost/pouet/compte.html', $this->getLocation());

Et ça marche pour tester du JS aussi ?

C'est justement pour ça que c'est fait. D'ailleurs selenium est en javascript (pour arriver à taper des trucs dans des formulaires et à envoyer, c'est sûr que le JS est le mieux).
 
Maintenant pour tester du JS pur, y'a aussi des frameworks de tests unitaires en JS

Déjà, c'est pas que c'est dégueu comme méthode mais un peu, quand même

Sinon, un truc du genre

<a onclick="Cart.updateQty(x,y,Cart.down)">blabla</a>

'update': function (x, y, fun) {
    // stuff
    fun()
}

(je sais plus si ça colle une bound function en référence ou pas, en JS)
Ou alors il y a la simple possibilité de dire

'update': function (x, y, action) {
    // do stuff
    Cart[action]();
}

$this->open('http://localhost/pouet/login.html');
 
$this->type('userid', 'user1');
$this->type('userpass', 'passe1');
$this->click('//form[@id="loginForm"]//input[@type="submit"]');
$this->waitForPageToLoad(10000);
 
$this->assertEquals('http://localhost/pouet/compte.html', $this->getLocation());

Je vois absolument pas l'intéret d'un truc pareil, le click/redirection c'est juste un side effect d'une vérification de mot de passe/login avec succès.
 

 
Euh, fonction()? Je suis pas sur que ça fonctionne
 

function(fun) {
     fun();
}

C'est juste un exemple de comment ça marche. J'avais ça au début, maintenant j'ai remplacé par test unitaire du controller + mock de la réponse HTTP pour vérifier que la redirection se fasse bien
 
Maintenant ça permet de tester certains trucs, genre de l'ajasque et tout

Ouais mais nan, je vois pas ce que viens foutre le GUI dans des tests applicatifs
 
Tu peux très bien écrire 80% de l'appli sans avoir ouvert un navigateur (ce qui plaira surement à ton patron   ) sans avoir à te restreindre à un env particulier (bien sur y'a des work around pour les navigateurs) mais c'est pas un click sur un boutton qui doit valider ton appli

Je viens de te dire que c'était un exemple
 
Y'a d'autres trucs très utiles à tester dans le navigateur, surtout des scripts ajax. Genre un diaporama en ajax, faut s'assurer que quand on clique sur "image suivante", y'a bien l'image suivante qui est fetchée et affichée. D'où l'interêt de Selenium

Tu contredis mon message en contredisant ta propre contradiction suite à une contradiction qui contredisait ton precédent message. Très fort.
 

• Que l'image soit affichée (ou pas), c'est un effet de bord lié à l'implementation dans le navigateur.
• Le clic c'est un appel de fonction.
• Le fetching c'est un appel de fonction.

A part le premier point, tout peut être mocker, et donc testé sans navigo. Ce qui te permet :
 

• D'éviter de te baser sur une implé en particulier pour créer la partie logique
• D'éviter de te baser sur la GUI pour créer ta logique (genre récupèrer le nom d'une class et admettre qu'une opération x à été un succès, or whatever)
• De créer juste ce qu'il faut comme interface entre la logique et la representation
• De mieux séparer les couches de ton code
• De tester le comportement de l'appli et pas de son implé dans un env x ou y