¿Cómo deberían organizarse los archivos de especificaciones en una aplicación javascript utilizando MVC

Question

? Me gustaría conocer su opinión acerca de cómo organizaría los archivos/directores en una gran aplicación web utilizando MVC (por ejemplo, backbone).
Haría lo siguiente (*). Por favor, dime tu opinión.

---

(*)

js 
js/models/myModel.js 
js/collections/myCollection.js 
js/views/myView.js 
spec/model/myModel.spec.js 
spec/collections/myCollection.spec.js 
spec/views/myView.spec.js 

Answer 1

se puede encontrar un buen ejemplo de cómo organizar su aplicación a este enlace

Backbone Jasmine examples

Se ve más o menos como su aplicación.

Answer 2

Así es como me he organizado tradicionalmente mis archivos. Sin embargo, he descubierto que con aplicaciones más grandes me resulta realmente complicado mantener todo organizado, con un nombre único, etc. Una 'nueva' manera de hacerlo es organizar mis archivos por función en lugar de por tipo. Así, por ejemplo:

js/feature1/someView.js 
js/feature1/someController.js 
js/feature1/someTemplate.html 
js/feature1/someModel.js 

embargo, muchas veces no son globales "cosas" que usted necesita, al igual que el "usuario" o una colección de sitios que el usuario ha construido. Por lo tanto:

js/application/model/user.js 
js/application/collection/location.js 

Este patrón se sugirió a mí, porque entonces se puede trabajar en conjuntos de características, paquete y desplegarlas usando RequireJS con relativamente poco esfuerzo. También reduce la posibilidad de que se produzcan dependencias entre los conjuntos de características, por lo que si desea eliminar una característica o actualizarla con un código completamente nuevo, puede reemplazar una carpeta de "cosas" en lugar de buscar cada archivo. Además, en IDE, simplemente hace que los archivos en los que está trabajando sean más fáciles de encontrar.

Mis dos centavos.

Editar: ¿Qué hay de los archivos de especificaciones?

Algunas consideraciones: solo tendrá que elegir la que le parezca más natural, creo.

1. Puede seguir el mismo patrón de 'carpeta de características' con los archivos de especificaciones. Lo bueno es que todas las especificaciones están en un solo lugar. La desventaja es que ahora, al igual que lo que está haciendo actualmente, tiene que ubicar los archivos de una característica.
2. Puede poner las especificaciones en una carpeta 'spec' de la carpeta de características. Lo bueno es que ahora tiene paquetes reales que pueden envolverse en un único archivo comprimido sin posibilidad de afectar a otro trabajo. También es más fácil encontrar archivos directamente relacionados para escribir pruebas; todos están en la misma carpeta principal. La desventaja es que ahora su código de producción y código de prueba se encuentra en la misma carpeta y lo publica (posiblemente) en todo el mundo. De acuerdo, probablemente termines compilando el javascript de producción en un archivo en algún momento ... así que no estoy seguro de que sea un gran problema.
3. Mi sugerencia: si se trata de una aplicación de gran tamaño y supongo que tendrá algunas manos tocando los archivos, deje algo así como un archivo 'package.json/yml/xml' en la carpeta. Allí, enumere la producción, las especificaciones y cualquier archivo de datos que necesite para la prueba (lo más probable es que escriba un guión rápido para hacer esto por usted). Luego escriba una secuencia de comandos rápida para buscar en su carpeta de origen los archivos 'package.whateverYouChose', obtenga los archivos de prueba y luego construya la página de prueba de la unidad con ella. Entonces, digamos que agregas otro paquete ... ejecuta 'updateSpecRunner' o lo que sea que nombres el script, y te generará otro archivo SpecRunner.html (o lo que sea que hayas llamado el archivo en el que ejecutas las especificaciones). Luego puede probarlo manualmente en un navegador, o automatizarlo usando phantomjs/rhino.

¿Tiene sentido?