| | 226 | |
| | 227 | === Javascript test framework === |
| | 228 | * '''Complexity:''' Low |
| | 229 | |
| | 230 | Django has an extensive test framework for Python code, a suite of tools to make testing server-side testing easier, and a project policy that new code is added without tests. This has been a significant contributor to the stability of Django as a project. |
| | 231 | |
| | 232 | However, Django also has client-side components, and these are not tested. Django doesn't currently have any systematic way to test Javascript. As a result, large parts of Django's public-facing code are not tested, and are prone to regressions and failures -- most notably, Django's admin, and the handling of inline form elements. |
| | 233 | |
| | 234 | We need a set of tools that allow us to test the Javascript code that forms part of Django's codebase, and a set of tests to validate the behavior of contrib.admin's widgets (and other admin components). |
| | 235 | |
| | 236 | Issues to consider: |
| | 237 | * How to handle cross-browser differences? Should we use a tool like Selenium to do live tests, or write genuine unit tests of Javascript as a scripting language? |
| | 238 | * How to clearly identify javascript tests at runtime? It should be possible to "just run the GUI tests" or "just run the code tests". This may tie into a broader requirement to differentiate "integration tests" (which validate that an app is installed correctly) from "system tests" (which validate that an app works correctly internally) |
| | 239 | |
| | 240 | See also: |
| | 241 | * #15569 and #14303 (a series of bugs and regressions that should have been caught and tested) |
| | 242 | * #2879 |
| | 243 | * #13873 |