HTML and CSS Reference
In-Depth Information
Testing your mobile web application is one of the most overlooked aspects of
the development cycle for new web developers. Most new mobile web
developers will simply load their web site on a mobile device and then play with
it to see whether it works. This can be laborious as you add more features, and
you really don't know what's going on inside your code. As you begin to write
more object-oriented code, you begin to see the complexity of your application
grow (in an organized way). You can test each unit of code, based on what you
put in and what you expect to get out.
For instance, in previous chapters, you touched upon creating models to store
data within your application. The integrity of your presentation and the logic
behind your application really relies on how these models accept and output
data through getters, setters, and other model-based methods. You can write a
suite of tests, based around each unit of code, with what you put in and what
you expect to get back. This method of testing is known as unit testing. Unit
testing allows you to test each method in your application. The more unit tests
that you write for each aspect of your project, the more confident you should be
that the application will work. This is known as code coverage. Keep in mind
that unit tests will cover only a certain percentage of your code, and you should
aim for at least 80 percent code coverage.
By creating unit tests, you can run a series of tests all at once, which target
every target web browser. This should give you the confidence that your code is
working as it should. This is especially helpful when a new browser or browser
version is released, as you can ensure that your JavaScript code is compatible
with the new browser by running the unit tests in it.
Deploying Your Application
Your application can be deployed in many ways. The most common method is
to deploy it through FTP (File Transfer Protocol) or SFTP (Secure File Transfer
Protocol). More often than not, you will have a production server where your
production code sits, a development server where you test your latest integrated
code, and a local development server. There are other environments that you
might want to create, such as a preproduction server, which will mimic the exact
configuration of the production server, and you might want to create a staging
server where a client or testers will test your final code before it's put into
Managing all of these environments and their code base can be problematic,
and manually deploying code changes with every commit to several
Search WWH ::

Custom Search