Leaflet/spec/suites/LeafletSpec.js

describe('L#noConflict', function() {
	it('restores the previous L value and returns Leaflet namespace', function(){

		expect(L.version).toBeDefined();

		var L2 = L.noConflict();

		expect(L).toEqual('test');
		expect(L2.version).toBeDefined();

		window.L = L2;
	});
});
namespace handling improvements, spec for noConflict 2010-09-04 00:49:32 +08:00			`describe('L#noConflict', function() {`
Omit "should" in spec descriptions The rationale is this: the spec string describes the expected behavior unconditionally. The code examples, on the other hand, set up an expectation that is tested with the call to the expect method. The code examples can violate the expectation, but the spec string does not. The value of the spec string is as clearly as possible describing the behavior. Including “should” in that description adds no value. (From http://rubyspec.org/style_guide/) 2013-02-20 04:41:48 +08:00			`it('restores the previous L value and returns Leaflet namespace', function(){`
fix specs sometimes failing 2013-02-05 23:00:38 +08:00
Fix up the unit tests. Polyline.closestLayerPoint and noConflict were broken. 2012-06-25 08:16:46 +08:00			`expect(L.version).toBeDefined();`
fix specs sometimes failing 2013-02-05 23:00:38 +08:00
namespace handling improvements, spec for noConflict 2010-09-04 00:49:32 +08:00			`var L2 = L.noConflict();`
Fix up the unit tests. Polyline.closestLayerPoint and noConflict were broken. 2012-06-25 08:16:46 +08:00
			`expect(L).toEqual('test');`
			`expect(L2.version).toBeDefined();`
fix specs sometimes failing 2013-02-05 23:00:38 +08:00
			`window.L = L2;`
namespace handling improvements, spec for noConflict 2010-09-04 00:49:32 +08:00			`});`
fix specs sometimes failing 2013-02-05 23:00:38 +08:00			`});`