TPR9: Test-driven Development for Web Applications

[Intro Music]

Announcer: You’re listening to one in a series of presentations from the 2008 HighEdWeb Conference in Springfield, Missouri.

Brett Bieber:� Good morning.� Was everyone in here for the previous presentation of Agile?� Well, he set me up great so if you are, you have all the theory behind what I�m going to be talking about in a little bit more technical detail.� So if you weren�t, it was a very good presentation.� He gave some introduction on all of the these topics that I�m going to be talking about, but this one is a little more technical so hopefully it may give you some ideas to take back and implement yourself.

So first off, my name is Brett Bieber.� I�m from the University of Nebraska.� Yes, that Nebraska that Mizzou played last weekend.� Let�s not remind me of it, but I don�t play for the football.� I work in our communications office and I do web development so backend server stuff.� Who here is utilizing test-driven development?� We have four.� Ladies and gentlemen, I would like to introduce you to my co-presenters out here.� If you all just state your name and your institution.� No, I won�t ask you but please, I have been doing this very long so if you have any insight, you want to provide something, just speak out and let everybody know so hopefully we all can benefit from your expertise and everyone else in here.

About me, my first web page in 1995, the WayBack machine hasn�t been trying so this will give you a little bit of perspective about me, and it�s embarrassing out there but only I have the URL so you guys won�t be able to find it.� I�m an active developer in the PHP Pear community in the Pear project.� I submit some patches in the W3C_HTML validator, and I�m the steward for the PHP Savant templating system.� So the perspective that I�m be coming at you from is a PHP perspective.

So some of the examples I�m going to show you are related to PHP, PHPUnit, individual languages are going to have tools specific for them.� If you�re developing in dot-net or if you�re developing in Java, they�re going to be equivalent tools within your specific library, your specific language, so look for those tools and if you�re looking for any of those, maybe someone here can offer some help to you.

All right.� The topics I�m going to be talking about, test-driven development, unit testing, web applications, testing with Selenium, and continuous integration with CruiseControl.� So that�s what we�ll be covering today.

The first test-driven development is going to go over pretty quick but does everybody know who Joel Spolsky is?� Some people do, some people don�t.� He has a blog out there where he writes on software development.� He also has a couple of books out.� His first one is excellent, and if you�re a developer, you can read that, it has a lot of good insight in it.� He has what he calls The Joel Test: 12 Steps to Better Code. �If you can achieve these, you are programming at a professional level.� So does everyone kind of read through this here?� There�s a quote down here.� �If you�re operating at 10 or lower, you�ve got serious problems.� Most are running at about a two or a three.�

Okay.� We won�t ask everybody what number they�re at but how many are under five maybe?� How many are over five?� Excellent.� Okay.� So there�s a lot of room for improvement.� If you take back some of these things that I�m going to be talking about, you implement them, you�re going to get quite a few of these, but we�ll walk through and we�ll talk about some of them individually as we go through the different aspects.

All right, test-driven development, quick introduction here.� The basic concept is you write tests first and you test your application.� You write your test first, write tests that fail and then you implement the code that makes it pass.� It has a concept of the roots of this come out of eXtreme Programming where two developers are going to be sharing a keyboard and I really don�t see how that could actually work.� Does it work?� It does.� Most of the programmers that I know, myself included, are quite pretty arrogant and selfish people and so sharing is not something they�re used to do, but maybe it can work.

Design by contract, that�s another thing.� If you write these tests before you actually develop a code, you know what your program is supposed to do.� This is the contract between you and your users.� You�re writing the test, you specify how your program is supposed to function.� The tests are your contract with the users, and as long as the tests pass, the software should work as specified.

Another important point here, if a bug comes up, you should write a test which reproduces the bug and then fix the bug.� That�s all basically the theory, introduction for test-driven development.

We�re going to move right in on how to write these tests, okay?� Unit testing, a very important concept for test-driven development.� What you do basically, the concept is you take your entire application, you divide it up into individual units, individual pieces of logic that you want to test.� All of these little units can combine into one suite, so one suite would have all of these many different tests inside it.� And the goal is to make sure that you�re running these tests quick, make sure they run quick, make sure you run them often.� It does you no good if you write all these tests and you run them only once a month and find out things are broken.� So you make sure you run these all the time or on a regular basis.

Just to give you a basic introduction to this, if you don�t know what testing is all about, I�m going to give you a little introduction based on a simple web application that we have at our university.� This is called People Finder, our online directory for faculty, staff and students.� You type in a name, it gives you search results; very simple.� It connects to our LDAP directory and it gets information back.

I don�t know if we�ll be able to see this.� Can everyone see it?� It�s kind of tough.� It�s the accessibility.� If people were in here, I would be in trouble.� Wow, that really helps.� Whatever works best for you guys.

Here�s a simple test.� It�s PHP so it�s simple for me but it does read pretty easily.� First, we�re going to create a new People Finder object.� This is the object that�s going to have all of our logic in it.� We get the results from the method to get exact matches for Harvey Perlman.� That�s our chancellor so I use him as an example.

Here�s a simple test.� If the result that is returned is an array and the size of the result is one, and the first record in that, the given name is Harvey, hey, okay, we�re good.� There�s a test, very simple.� If any of those fail, error, something is wrong.� So I can run that, it gives me okay, I know that those three things work fine.� Very simple.� This is what I would consider a home-brewed testing environment.� You would write a test, you would say, okay, I want it to put out an okay message if something works okay.� I want it to put out fail if something fails.� Very simple.� We have a series of okay, it�s good.� Any error, there�s a problem.

There are some drawbacks to using this though, this sort of home-brewed testing.� It�s only easy to implement for simple checks.� You have to write if-else statements for every check.� What if you want more than okay or error?� Okay, only run test B if A is okay.� Or I want to expect an error in some cases.� I want more helpful error messages, like 2 plus 2 function returned 3 but I expected 4.� This is where the benefits of a unit testing framework can help. �All of your languages are going to have a framework out there that will give you an environment for testing and will give you a lot of these tests or code that you can reuse and then implement in your own language that you�re writing your code in to speed up your testing.

For example, this one would be an example using PHP unit which is a unit testing environment and we converted what we had before.� I don�t know how many lines it was before.� Now, we only have like five lines.� We do still do the initialization.� We created an object to get the result and then we have what we call assertions.� We assert something is true.� We assert it is false.� We assert it equals 1.� We assert the text Harvey is equal to what is returned for the given name, very simple, okay?

Unit testing frameworks, they follow something from called the xUnit or Beck testing framework, and this comes from Kent Beck of eXtreme programming thing, and he wrote an initial testing framework for the Smalltalk language.� The concepts within a unit testing framework, it tests pictures, tests suites, tests executions, tests assertions and all of these follow the same sort of design patterns.� So if you�d learned one in one language, you can apply it to other languages as well.

Here�s a simple test using PHP unit, very similar to what we had before, only now it added error messages that give me a little bit more detail about what�s going on.� Go back here.� If I run this, I get dots, it means they had passed.� �I� stands for incomplete, as in I haven�t implemented the test for that method yet, fairly simple.� If something fails, I get a difference.

For example in this one, I expected the string �Harv� but actually got �Harvey.�� I mistyped it intentionally so that it would show you guys what the differences would be if you�re comparing two strings that are returned.� So this is an example of a failed error message.

So does everybody understand what unit testing, kind of the concepts of it?� It seems pretty easy, right?� Okay.

What�s wrong?� Does anybody what�s wrong with the few examples that I just gave you?� Very good.� Anybody else?� Do you see anything wrong with what I�ve shown you?� Okay.� That�s good, very good.� Right.� Okay.

Let�s go back to this.� Assume I got a failure message and these are the three error messages that I also turned.� An array of results was not returned.� The size of the result set is not what was expected.� And Harvey was not returned.� What does that mean?� Do these messages tell you anything about what�s wrong?� Are we testing the right things at the right level?

So let�s look at this first one.� An array of results was not returned.� What could that possibly mean?� Someone broke the message return signature?� That could be a problem.

The second one, the size of the result set is not what was expected.� Let�s say it�s more.� Is there more than one Harvey Perlman?� There�s a Harvey, Jr. now where we have a new chancellor?� Maybe he�s gone.� Harvey was not returned.� Did he change his name?� Did we lose him?

So there are lots of problems with this.� What was the cause?� The LDAP directory was down.� The point here is you need to test at very small levels.� Test small pieces, not applications.� When you�re testing for unit testing, you�re testing very small pieces, okay?� You need to name your tests appropriately.� You need to give helpful information so when something fails, we know where to go looking for what the cause was, okay?

Some advice here.� Don�t test against live data unless you have to.� For some examples, there would be web services, a service that you actually don�t maintain.� In some cases, you may have to do that but ideally, you�re going to use mock objects, you�re going to return fake simulated data that makes the application appear that everything is working correctly.� Use test databases so you have sample data that you know so that things will work when you�re testing the logic of your application.� If your tests rely on previous pass or fails, you need to code them appropriately.

In our example, if the LDAP connection was down, there�s no point in testing how many results we get.� There�s no point in testing what the name was of what was returned.� So what I really want to emphasize is when you do unit testing, you do not want to send your developers down the wrong path trying to debug something where there�s something wrong.� So just use it with a little bit of caution.� Name your tests appropriately, test at very small levels and I think we�d be all right.

Benefits of unit testing.� What we�ve done was we�ve established a base for what our program is required to do.� We can make drastic changes.� I know that the program which is our contract with a user functions as expected, very important for refactoring.� We ensure that new features don�t break expected behavior.� We ensure new developers don�t break expected behavior.� We ensure past developers.� We ensure that you don�t break expected behavior.

Who develops web applications at their university?� Okay, everybody.� Are your applications important?� Do you think they�re important to you?� Would you be comfortable handing off your applications to somebody else to maintain?� If you have a test suite, you know you�re covered with tests, it�ll leave you in some depth.� You can hand it off and you could say, okay, this is how you run the test suite.� If you modify it, everything has to pass.� So it�s very important in terms of business continuity, especially if you have students working on something.� High rate of turnover, new developers coming in, someone needs to jump into an application, start modifying it or improving it; write the test, make sure that the test passed, you�d be all right.

Here�s a quote.� Even the dumbest developer can break a code.� Should we substitute here?� Even the smartest developer can break a code.

Code coverage and code analysis, let�s talk a little bit about this.� Unit test, if you have them, what you could get from that is code coverage analysis.� So yes, we test it, we test our application.� This answers how much, to what detail are you testing.� We have 100% method coverage.� What about decision branches within those methods?� What about every line of code, every input, every output?� Code coverage analysis can give you metrics based on the coverage of functions and statements and conditions� paths entry and exit.� It gives us confidence in the code that we�re using.� It gives us confidence we�ve inherited from someone else, confidence in the code that we�re delivering to someone, and confidence in the code we�re asking someone else to support for us or to make improvements.

For example, this is a code coverage analysis map.� It�s very graphical.� Each one of these blocks would be a file. �Each one of these would be a plus within that and the different colors to show you that code coverage, how well you have covered with your test.

This has a little summary on this side here.� This is the code coverage analysis for the CruiseControl project.� We have 84% method coverage, 87%, 85% line coverage.� So it gives you a lot of important information.� We know that we have 85% of the code behind our application tested that we can verify that it�s functioning correctly.

Here�s an example of a report for this simple application that we have for our directory.� It gives us code coverage analysis and in some methods here, we have each class is covered.� What about the methods within that class?� What about the lines within that?� Within this, we can actually see where we need to write more tests, where we need to improve the coverage.� Right here, we have 25% of the lines within this People Finder method, so we need to really improve that.� We dig deeper into the code coverage analysis.

We have this right here.� We can see the lines, the actual lines of code that need to be covered with unit tests.� So this is red.� I write a new test.� I run the code coverage analysis.� I can see, okay, now, I have covered these components.� I still have some that I need to work on here.� I write another test.� In this example, I�m getting a mock object.� I�m not connecting to the database, I�m not connecting to the directory, I�m getting a fake object which is going to allow me to examine this information and run the test on our logic and then our coverage will cover a couple more lines.

We still have a couple more.� I think I�m pretty confident in this coding.� Run it again.� We have a lot better code coverage analysis.� This is a very small project.� I�ve talked to some developers, a friend of mine who work at Ratheon.� They have 3 million lines of code.� They have five branches going on all at once.� They have future development, current development and then three past releases that they�re constantly developing.� It�s very important that you have these tests.� You can analyze the code and you can examine this in detail.

Does everyone have that?� Got it?� It seems pretty simple?

So now, when someone says this, we have 100% code coverage and all the tests passed.� Does anybody see anything wrong with this?� Does anybody want to comment?� Does anybody see anything, any flaws in this logic here?� Go ahead.

All possible inputs.� Very good, okay.� Also, it is possible to write tests that prove incorrect logic.� Oh really?� Did you test all input possibilities?� It could be infinite.� Did you test on the client�s machine?� There�s where the web applications come into play.� You test run; okay on the testing server.� But did it work on the director�s machine?

Web application.� What about web applications?� I just want to go back to this.� One point I wanted to make about that was when someone says something like that.� We have 100% test coverage.� Take that with a grain of salt.� There is no way that you can get 100% coverage and be completely confident.� You�ll never catch all the possible bugs but you can get close and you can do some of the best.� That�s what I wanted to get at there.

Web applications.� So we know our code works on the testing server.� Web applications have special needs, right?� Whenever someone reports a problem, what is the additional information we need to get from them?� What browser are you on?� What version?� What OS are you on?� All these additional questions, all these different aspects of how something can be rendered on the client machine, there are so many different variables.� The service sends the right HTML.� What if your designer hides that with JavaScript or CSS?� I actually had this problem once.� I had everything working correctly, hand it off to the designer, he used JavaScript and he hid the button which would allow you to submit an event within our event system.� I�m going, �Everything is fine.� I don�t see what the problem is.�� These are things we need to be focused on in terms of web applications and testing.

So how can we test in this environment?� Do we test the code?� Do we then hand it over to a human and have them manually click through everything?� This is where we have a solution that�s out there called browser-based testing in Selenium.� This is something someone might consider a functional test for your application.� Whereas unit testing is testing your logic on the server, this is actually you can think of it in terms of macros, automating a browser, going through a sequence of operations to make sure that your application functions correctly.

It runs on Windows, Mac OS X, Linux.� It�s a Java based system.� Browsers, it can test in Internet Explorer, Firefox, Safari and many others as well.

For example, I�ll give you a quick introduction on how to do this.� You can easily record and play back actions.� You can automate your browser and it can integrate with your global test suite.� That is very important for me.� If I�m writing a bunch of tests that test the logic, the unit test on my application, I can integrate additional tests which are going to automate the browser and test the functional testing as well and give me results.

Here�s a screen shot of the IDE.� I�m sure you guys have all installed Firefox extensions before.� You go to their website, click on it, it�s an IDE which goes into Firefox and just lets you record actions and then play them back.� Here�s an example.� I don�t know if you can see this but here we have a sequence of operations that I�ve recorded.� I open an address, I type Harvey Perlman within the huge search box.� I click the submit button.� I wait, verify text is present on the return.� I click a link, I verify that text is present on there and then I verify that the email address is there; simple.� But it�s very easy to create these simple tests.

Yes, it will.� As it�s recording, it automatically recognizes what fields you input it in and what links you�ve clicked on, and you can also customized these too.

So here�s just a larger screen shot of that where I�m having assertions within Selenium; are actually called verified.� They say verify text is present, verify the element is present.� They have a lot of different assertions to check; verify the number of elements and so on and so on.� Verify the object is present from the dump.

What you can do once you have one of these recorded actions, you could export it for your unit testing framework.� Here I have selected export to PHP.� What it�s going to give me is a test which I can integrate within my other code.� It gives me the PHP code which I can integrate into my test suite.� I can run this.� We start up the Selenium server, remote control which is going to be listening for connections.� I run it, I run my test and I can actually see it.� It pops up a browser, clicks through operations and then it returns me the results.

We got a video here I want to show you.� I don�t know if you can see it.� It�s only 18 seconds long and they have to play it a couple more times.� What it is, this is a screen capture of Selenium running on my machine, testing our event system, going through a sequence of operations.� All these have been automated.� There we go.� Done.� I�ll run it again.

We load it up.� We test the login.� We test creating an event, everything is okay.� It loads up Firefox again, logs in, selects a bunch of events, moves them around, does search, finds the result, adds to the calendar; very quick.� And you can test this in Firefox.� You can test the same operations in Internet Explorer or Safari, very helpful especially if you want to automate some sort of testing here.

What are you seeing?� Are you spying some problems here?� There are a lot of problems with some of these tests.� In unit testing and functional testing, you want to isolate everything so you want, if something fails earlier on the chain, you don�t want it to cancel out everything else.� So it�s very important to isolate testing, make sure your tests are isolated.

Go back to this here.� That gives you simple introduction.� Other use cases for this, how we use it, we log into the system, perform actions, verify results.� That�s how we test it against.

Automate accessibility checks.� There�s a possibility.� Has anyone ever used Cynthia Says?� Sorry, you submitted it too early.� There�s one minute.� A web address could submit, check for past automated verification, wait one minute, start with another address.� Those are just some ideas of how you can automate some browser actions.� Does anybody else have some other examples?� Has anybody used Selenium?� What do you use it for?� Use it for sequences of registration forms.

Just keep in mind that we�re testing everything rendered on the browser so we�re testing the combination of HTML, CSS and JavaScript.� Also, when something like this fails, it is kind of hard to find out where actually that failed.� Was it the CSS that failed?� Was it the JavaScript?� So just keep that in mind.

Everyone understand those concepts?� It seems pretty easy.

Here�s a quote from a developer.� This came across my reader recently.� �Have a continuous integration solution in place.� Really.� If you don�t, you just burn money by writing tests.� I would go so far as to say if you don�t have continuous integration, you should stop writing unit tests and do click tests.�� I somewhat disagree with this guy but he makes a good point for why continuous integration is important.

Does everyone here know what continuous integration is?� Has anyone used it?� Testimonials, okay.� You love it, all right.

I kind of disagree with that quote.� Tests can be the foundation for your continuous integration environment, cart before the horse.� They can serve a secondary documentation.� There have been some projects where I see their tests and that actually gives me insight into how the program is supposed to function.

CI, continuous integration, can serve other purposes besides just unit testing.� It can build API documentation for you automatically.� You can run coding standards tests.

This is a fellow developer.� He says, �Continuous integration without unit test can have benefits.� At a minimum, you�ve defined a one-step build process and that�s a huge benefit.�

Continuous integration, what is it?� Martin Fowler has a lot of information on it.� I would recommend this article to everybody to just read if you�re interested at all.� The idea, if you weren�t in the Agile talk previously, developers continuously or more frequently integrate their code which means that you have a team of developers.� You�re all contributing the code and you�re contributing as quickly as possible once you make changes.

Each developer is committing changes to the source code repository daily.� You�re committing your changes.� Why would we do this?� You ensure that all the developers are working with the latest code, working or not.� Other developers need to know immediately if an interface or a method signature has changed.� Everyone sees the progress is being made.� This is good for managers also.� They can see that developers are actually working.

This last one, 5 PM, leaving for the day, someone drops in 500 lines of code into the repository.� It�s a pain for all the other developers and it�s a danger to the build.� There is a developer on our campus, very active in the PHP community.� He�s currently working on the namespaces within PHP and he travels a lot, so he�s constantly away from the internet.� He�ll come in and he�ll drop just like this, 500 lines of code and you have everyone else who�s developing with this has to understand his whole train of thought that he went through on that seven-hour plane ride to understand what his thinking was and what his process was.

In a continuous integration environment, you�re contributing all the time.� You can see those changes.� You can understand and see what the other people are thinking.

CruiseControl is an application which implements a continuous integration environment.� I say framework.� Some might not call it a framework but it�s a continuous build or integration process.� The overview is you tell this application how do you build your application.� Do you use Ant?� Do you use GNU Make?� Do you use MSBuild?� Do you use some other method of building your project or deploying it or testing it?� You tell it how and then you can define dashboard notification, plugins, modules.� Okay, notify a developer when they�ve broken the build.� This I think is very powerful.� You commit some code which broke a test.� You notify that developer.� You broke the system, you need to fix it.� And you notify him right away.� That�s very important.� You can send if you have RSS feed.� You can send an IM.� You can email them.

I�m not going to go into much of the details about how to configure it because it may be specific for your specific build environment that you�re working on or your specific language but there�s a lot of helpful documentation out there.

This is an example of the dashboard for a project at I have.� This gives a breakdown of the builds, how many have passed, how many have failed.� In my environment for this one, I have started up our testing machine whenever someone starts working on it.� I don�t have it running always.� I just start it up and stop it.� But you can also have graphs based on unit test coverage which I don�t have on this one.� How many unit tests have passed or failed, test code ratio, coding violations.� If you�re working within a team of developers, it might be a good idea to adopt some sort of coding standards for your language.� There�s a lot of them out there, and I really think it�s going to help.� If you have multiple developers contributing code, have everyone work on the same standards so you�re all writing codes at the same sort of specs and you can expect how things are supposed to be written.

This is one where it�s a new project.� We have all the unit tests written and we have not had a working build yet.� We have 125 tests that passed.� We have 40 or so that have failed.� And once you got this running, we have started working on that, working through those unit tests and making them pass.

Other things which might be helpful are test execution time; continuous integration can monitor that for you.� If you see that your build is taking a huge amount of time longer, maybe you need to rethink of take a look at what those commits were, what those changes were that affected the build time.

Let�s go back here to the Joel Test.� We have these 12 points, and there�s a quote here, �10 or lower and you�ve got serious problems.� Most are running at about a two or a three.�� I was probably running at maybe a one or a two before I started looking at some of these.� So if you�re running low, don�t worry about it.� That�s where I think a lot of us start.

If you implement a lot of this stuff using source code management, using unit testing, you can get a lot of these.� You can cover a lot of these.� Do you use source control?� Can you make a build in one step?� Do you make daily builds?� Do you have a bug database?� Do you fix the bugs, write tests before writing new code?� Do you have an up to date schedule?� Do you have a spec?� That spec can be tied to those tests that you have written before.� The spec can really help you understand what your program is supposed to do and how it�s supposed to do it.� Do you have testers?

So implementing a lot of this stuff can get you a lot of these on the road towards professional software development.

Some empirical evidence.� I think I wouldn�t do it justice if I didn�t.� This is actually a research that was done by a guy in Canada on the effectiveness of test first, so test-driven development.� He had students develop software, the same application, and he had develop it, one, they just went started writing code and, one, he had them write the test before they wrote the code.� It�s a small test and I think there needs to be a lot more work done but this research paper showed that using the test first development, it improves the productivity, it gives the developers a better understanding of the requirements, it helps you reduce the scope of the individual task and it reduces debugging and rework effort.

I don�t think that they found that it actually made it faster for you to develop the applications.� It improved the productivity because those programmers weren�t in that writer�s block trying to figure out, how is this supposed to be implemented?� They understood that already, but it improved in a lot of other ways. �I do think there needs to be a lot more research but this is some research that has been already.

Discussion and questions.� Anybody have any questions?� I don�t know if I can answer them but I�d be happy to try.

A lot of customers, I don�t know, that�s probably a bad term, the people that we�re dealing with, they don�t understand the intricacies of what these, the decisions and the business logic.� But when you go through this process as the developers, you can see some of these and give them sort of a forecast, okay, these are the decisions we�re going to need to be made and then present those.� It gives the developers a lot better understanding of what the program is expected to do so they can communicate clearly with your clients, who you�re the application for and get the information that you need.� So it helps you develop a stronger relationship between those two.

Yes?

In terms of testing, how do I handle database integration and testing?� Okay.� What I do is I actually take snapshots of the database for data that is secure and I can expect how it is.� Before I run the test on that data, I set up the database, initialize it to that state and then I run all my tests and then I go on to the next ones which may need to set up the database in a different way, but I use test databases and test data.� Does that answer the question?

I do not have the testing environment connected to the live database at all so I have a completely separate environment for the continuous integration system and it just talks to its own database.

Those are usually separate tools but they are related.� The tool that actually runs your unit tests, it�s going to have to build a report or instrument your program to determine which lines of code were actually touched and then provide that to something else.� In some cases, I think they may be integrated but all the ones that I�ve seen are completely separate tools.� The testing framework actually gives you a report of the lines that were touched and then something that actually analyzes that and gives you metrics and graphs, that�s going to be a separate tool as far as I know unless someone else has other experience.

Any other questions?� Right here.� Okay.

The question was C++ would be a compiled language.� PHP is interpreted language.� What do you consider actually a build if it�s an interpreted language?� Is that kind of the question?

The build process that I use in PHP usually just package up the code.� They may build an API documentation and package that in, run through a link checker, make sure there is no syntax errors; basic steps like that but there aren�t any real compiled steps or anything that takes significant amount of time in an interpreted language.� That�s basically what my build process is.

I think the best way is to create mock objects of what you expect how it should function, the data and the format that you should expect, and then compare the actual results.� In some of those, you�re going to have to test against those systems.� For example, the web service provides a syntax or provides XML to you.� You�re going to have to make sure that it conforms to that same format.� Know what you expect, test against that so that immediately, you have it in that integration environment so that it�s continuously checking it and if something comes up like a fix from your vendor comes through and changes out of format, you�re going to know about it immediately.� That�s the only advice I can offer there.

Sure.

What am I using for PHP build processing?

I�m in the Pear project which means that I use their build process and their distribution mechanisms.� So what that is, it actually packages up code, provides a package manifest in there and allows you to install and upgrade different versions and handles all that for you.� So the tools that I�m using are Pear but there�s also for PHP there�s Fink.� Fink is not GNU Make.

The project for CruiseControl is actually called phpUnderControl.� I don�t know if you�ve seen that before, but it integrates with CruiseControl and it gives you a lot of those code metrics.� Also, PHP CodeSniffer which is a project within Pear.� It actually analyzes your code, make sure that it follows some standard that you specify, whether it�s a Zen standard or it�s the Pear coding standards.� So there are a couple of tools for you.� I also have some other resources at the end of this.

You found that there are some problems with the Zen framework and Zen code.� Right.

Now, we�re kind of getting into some specific PHP questions but I can answer some of those specific PHP questions afterwards.

Is that it?� One more minute.

With Pear projects, are you talking about

Right now, I�m working on the Pear 2 installer which is the next version of what they call Pyrus which will be in the installer for the next version of Pear.� Right now, I�m on the Pear group so I actually make decisions within there about where the project is going and things like that.

Because it maintains backwards compatibility with PHP 4.� It�s the Achilles� heel of Pear.� It works on all the platforms.

Good.

Thanks everybody for coming.� Thanks.

[Applause]

Announcer: For more presentations from the 2008 HighEdWeb Conference visit HighEdWeb.org/2008 or sign up for our podcast and feed at HighEdWeb.org/podcast.xml

[End of Music]