4/5/15 ChaptersListPageGenerator code and tests

Repo diff
ChaptersListPageGenerator code
ChaptersListPageGenerator tests

For some reason, there are two ways to test equality in our tests, assert.equal() and expect(). I think the former is the mocha expression, and the latter is the chai expression. I tried to convert all our tests over to the expect() syntax. I also found this page, which was helpful for writing the expect statements.

In testing the chapters list page generator, I made my own stub for HttpRequestHandler, which is used to fetch the RSS chapter data that populates the chapters list. There's a stubbing/mocking library we might want to look into as well.

I wasn't quite sure how to test the output of #generatePage since it's all within the page elements, and this is what I ended up with. I also found that I had to explicitly instantiate the <ul> targeted by #pageGenerate as a jQuery Mobile listview, otherwise this line in app.js would cause an error saying that the listview had not been initialized.

I added a property to karma.conf.js to allow console.log statements to be outputted to the server console, which is helpful for debugging the tests

I don't think we need to test the private methods of ChapterListPageGenerator; they aren't part of any public interface, so there is no risk of cascading changes causing problems beyond #generatePage. if something is changed.

I looked at how to make public and private methods in an object, and how inheritance works in JavaScript:

	function Foo(args) {
	var private_variable = args.private_var;
	this.public_variable = args.public_var;
	this.public_method = function () { };
	function private_method() { }
	}

view raw function_scope_example.js hosted with ❤ by GitHub

	function Foo() {
	this.doOneThing = function () { return 'one done.'; };
	}
	var foo = new Foo();
	function Bar() {
	this.doAnotherThing = function () { return 'another done.'; };
	}
	var bar = new Bar();
	bar.doOneThing() //=> TypeError: undefined is not a function (#doOneThing is undefined)
	bar.doAnotherThing() //=> 'another done.'
	Bar.prototype = foo; // Prototyping is like inheritance, but more flexible
	// Can't do Bar.prototype Foo(), must use an actual instance, like foo or new Foo()
	bar.doOneThing() //=> same TypeError as before
	var bar2 = new Bar();
	bar2.doOneThing(); //=> 'one done.' -- It works!
	bar2.doAnotherThing() //=> 'another done.'

view raw object_inheritance_example.js hosted with ❤ by GitHub

With a Foo() object set as Bar's prototype, all new Bar objects to send anything that they don't know how to handle up the message chain to Foo. So a method defined in Bar would override an identical method in Foo, but a method defined in Foo and not in Bar will work as though it is being called on Foo directly. This source was helpful in figuring stuff out.