Tests are essential to make this module truly reliable. Let's make this happen.

Comments

Wim Leers’s picture

Status: Active » Needs work

Initial tests committed. They use DrupalUnitTestCase, for far greater testing speed. I've hacked my way around the fact that it doesn't support variable_*() by default — we need that for the tests, since the CDN module makes many decisions based on these.

These tests cover:
- detection of HTTP/HTTPS requests
- parsing of CDN mapping + deciding which mapping to use based on the protocol of the current request (HTTP or HTTPS)

As such, they will help with implementing #1452092: Automatically distribute certain filetypes over multiple CDNs without causing regressions.

Commit: http://drupalcode.org/project/cdn.git/commit/b3d6165.

Wim Leers’s picture

andreiashu’s picture

Woa!!! +10 :)
I'll take a look over this soon.
Thanks!

Wim Leers’s picture

The first test failed: http://qa.drupal.org/pifr/test/235088. Because Drupal's testing system sucks so badly that it's not really running in isolation on my system… hurray!

Follow-up commit that fixed this: http://drupalcode.org/project/cdn.git/commit/a4ab5ea. Fingers crossed!

Wim Leers’s picture

Wim Leers’s picture

Wim Leers’s picture

Wim Leers’s picture

Title: Tests! » Unit tests!
Status: Needs work » Fixed

The most critical components are now unit tested. As bugs are uncovered and features are added, they're tightened further: #1593930: cdn_get_domains() is broken for auto-balancing when using protocol-relative domains: fix + tighten tests.

Note that we do *not* have integration tests, feature tests, etc., just unit tests. This is probably going to be sufficient, at least for now.

EDIT: or rather, it's not necessarily sufficient, but it gives us the biggest return on investment :) (i.e. the most bug-sensitive parts are unit tested.)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.