Click here to Skip to main content
Click here to Skip to main content
Technical Blog

#titanium #appcelerator testing with ti.mocha

, 24 Jun 2014 MIT
Rate this:
Please Sign up or sign in to vote.
I've recently start working with titanium building native mobile applications. Titanium provides you a javascript framework that is wired to native code and more important to native UI controls, trying this way to reduce the UI lag that you normally see on mobile browser application built using angu

I've recently start working with titanium building native mobile applications. Titanium provides you a javascript framework that is wired to native code and more important to native UI controls, trying this way to reduce the UI lag that you normally see on mobile browser application built using angular, ember, vanilla javascript, ...

Testing browser based applications

Unit tests are one of those things that both backend and frontend people should do (I'm not referring to UI tests here!). On web based applications you can generally use Jasmine or Mocha to create these tests.

To create unit tests using mocha or jasmine you normally:

  • Create a CommonJS bundle ( maybe with source maps enabled, for better debug! ) that you can load from a browser.

  • Using a browser or phantomJS you create the bootstrap web page ( normally this is a grunt/gulp task ).

  • Run the tests, a normal web page!

In the end you get something that you can wire with your CI tool.

Grunt running Jasmine test

Testing titanium applications using ti.mocha

So one of the first things I've searched from the beginning of my titanium journey was how to unit test my code to not get so nervous in every commit!

When searching for a solution ti.mocha was one of the few relevant results that I've got.

I've created the following github repo that explains ti.mocha integration. If you're trying to understand how ti.mocha works you can find a ready to go example on the next link.

https://github.com/aetheon/ti.mocha.example

ti.mocha execution

After try it, here are some thoughts that popped up my mind ( view app entry point ):

  • Pitfall To test you must run the device simulator in test mode! This can be a very slow process...

  • Pitfall Very tight integration of testing code and application code. You'll end up maintaining two applications, the real one and the testing one.

  • Pitfall|Cool You are running unit tests in the 'real' environment. No mocked stuff there! ( I suppose this depends on the use case, but I think it's a pitfall )

  • Pitfall Integration with CI tool. Because you need to run the simulator you cannot easily get the termination code of the process.

Titanium testing utopia

In summary what I would like is a testing framework that:

  • is fast to run ( similar to grunt-contrib-jasmine )

  • mocks titanium and alloy API ( TI.?, Alloy.createWidget)

  • observe call TI/Alloy, e.g. expect(Alloy.createWidget).toHaveBeenCalled();

  • testing framework that can help describe the application by writing tests without being so tightly coupled to Titanium.

There's not a lot of information about this ou there, so let me know what you think.

License

This article, along with any associated source code and files, is licensed under The MIT License

Share

About the Author

aetheon
Web Developer
Portugal Portugal
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150123.1 | Last Updated 24 Jun 2014
Article Copyright 2014 by aetheon
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid