<br><br><div class="gmail_quote">On Thu, Nov 20, 2008 at 9:52 AM, C. Titus Brown <span dir="ltr"><<a href="mailto:ctb@msu.edu">ctb@msu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Thu, Nov 20, 2008 at 01:37:56AM -0500, Noah Gift wrote:<br>
-> The web is a weird world, because of the mixture of technologies, like PHP,<br>
<div><div></div><div class="Wj3C7c">-> javascript, ruby, python, perl, actionscript, etc, that are often quick and<br>
-> dirty functions in a couple of files. I have a friend that has to deploy<br>
-> applications quickly for many of these languages, it isn't me I promise :),<br>
-> and he often finds that a developer tells him. Oh, it works, don't worry,<br>
-> just update the production site...and do it NOW!<br>
-> About 50% of the time, things break, when he goes to deploy, and it turns<br>
-> out to be a hardcoded database password that is wrong, absolute paths, and<br>
-> more. Other than telling this guy to get another job, which is probably a<br>
-> wise move, is there a commonly accepted minimum level of testing that a web<br>
-> developer should ethically subscribe to across all languages?<br>
-><br>
-> If I was in his position, I would tell the developer(s) that routinely give<br>
-> him broken web apps that they were poor developers for not including at<br>
-> least some basic tests. These could even be minimal, like a script that<br>
-> connects to the database and tests a couple of URL parameters for example.<br>
-> Is there anything I could point him to that could help convince the CTO and<br>
-> developers at this company that testing is just ethical?<br>
<br>
</div></div>Layering additional requirements on people (whether or not you tell them<br>
that they suck first) </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> generally doesn't work unless you're in a position<br>
of power, and even then they often find a way around your requirements.<br>
So I think it's unlikely to work well.<br></blockquote><div><br></div><div>I agree, yet, this is a behavioral issue remains an issue for web developers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Why don't you tell your friend to build some simple smoke tests --<br>
using Selenium or twill, for example -- that exercise the deployed<br>
site(s)? Then he can figure out quickly and easily if things are<br>
broken.</blockquote><div><br></div><div>That is pretty much what I told him a while ago, that he needs to use CYA techniques like writing tests for the developers that don't write their own tests, and also monitoring website status codes covertly in case a rogue developer does an svn update using the root account which is publicly available, and breaks everything. One issue is that a lot of these sites are flash, too, which do "fancy stuff", but maybe make one call to a database to pull something out. See this is the kind of stuff I want you and Grig to cover in a book, covert, black ops testing. There is already a book on how to become a javascript ninja, how about how to be a testing ninja that can test ANYTHING, even code he didn't write.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Another strategy might be for him to set up a simple staging environment<br>
on his own and deploy things there first; that would let him break<br>
something other than the production site. If he automates the<br>
deployment from staging -> production and also automates the test<br>
running, then he'll be just as fast when it all works but he won't<br>
deploy broken stuff.</blockquote><div><br></div><div>This is a pretty useful technique as well, if you are in an environment that lets someone have that much discipline. I think people have the ability to walk in and say, this site goes live in 5 minutes. It also brings up an important issue. Python doesn't have a deployment tool, that is widely used and easy to use, like Ruby does with Capistrano, or Puppet, that I am aware of. I was talking to Kevin Dangoor about this during his Paver talk at PyWorks, <a href="http://www.blueskyonmars.com/projects/paver/">http://www.blueskyonmars.com/projects/paver/</a>. I could make the argument that web testing and deployment are closely related tasks, and perhaps deployment even falls under the umbrella of testing.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Both of these strategies duck the systemic problem (developers not<br>
testing) but make it easier for your "friend" to do a good job.<br></blockquote><div><br></div><div>I still think there is a minimal level of testing, in any language, that should come with a web app, and that it could be summarized in an elegant way that wasn't too condescending. Where is our generations Nancy Reagan, "just say no" to untested web apps?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
--titus<br>
<font color="#888888">--<br>
C. Titus Brown, <a href="mailto:ctb@msu.edu">ctb@msu.edu</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Noah Gift<br><a href="http://noahgift.com">http://noahgift.com</a><br>