Pregunta

Cuando su aplicación toma algunos (~ 5) parámetros de configuración, y la aplicación se va para ser utilizado por usuarios no tecnológicos (es decir, KISS ), ¿cómo maneja habitualmente la lectura? opciones de configuración, y luego pasar los parámetros entre objetos / funciones (múltiples módulos)?

Ejemplos de opciones: directorios de entrada y salida / nombres de archivo, nivel de detalle.

Generalmente uso optparse (Python) y paso las opciones / parámetros como argumentos; pero me pregunto si es más común usar un texto de configuración archivo que es leído directamente por los objetos de todos los módulos (pero entonces, ¿no es esto como tener variables 'globales' ?, y sin que nadie 'sea dueño' del estado?).

Otro problema típico son las pruebas unitarias; si quiero probar cada unidad módulo individual de forma independiente, un módulo particular solo puede requerir 1 de las 5 opciones de configuración; ¿Cómo se desacopla habitualmente? módulos / objetos del resto de la aplicación, y aún así le permiten acepta 1 o 2 parámetros requeridos (¿el marco de prueba de la unidad de alguna manera invocar o hacerse cargo de la funcionalidad de configuración)?

Supongo que no existe una forma correcta única de hacer esto, pero sería Sería interesante leer sobre varios enfoques o patrones conocidos.

¿Fue útil?

Solución 2

"Counts answer"
Please update these counts and feel free to add/modify.

Do you usually read config options via:
- command-line/gui options : 1
- a config text file       : 0


How do multiple modules/objects have access to these options?
- they receive them from the caller as an argument: 1
- read them directly from the config text file:     0


When doing unit-testing of a single module (NOT the "main" module)
and the module uses one option, e.g. input filename:
- unit-test framework provides own "simplified" config functionality: 0
- unit-test framework invokes main app's config functionality:        1


Do you use:
- optparse:  1
- getopt:    0
- others?


Please list any config management "design pattern" 
(usable in Python) and add a count if you use it - thanks.
- 
-

Otros consejos

¿Sueles leer las opciones de configuración a través de: - opciones de línea de comandos / gui - un archivo de texto de configuración

Ambos. Usamos settings.py y logging.ini de Django. También utilizamos opciones de línea de comandos y argumentos para las opciones que cambian con más frecuencia.

¿Cómo tienen acceso a estas opciones múltiples módulos / objetos?

  • settings.py; logging.ini - no puedo decir.
  • Nuestras opciones son privadas para el programa principal y se utilizan para crear
    argumentos a funciones o inicializadores de objeto.

[Compartir las opciones de optparse es un gran dolor en el cuello e innecesariamente une muchas cosas en un lío incontestable].

Al hacer pruebas unitarias de un solo módulo (NO el módulo principal): (por ejemplo, opción de lectura que especifica el nombre de archivo de entrada)

[No puedo analizar la pregunta. Supongo que esto es "¿cómo se prueba cuando hay opciones?"

La respuesta es: no lo hacemos. Como solo el método principal analiza las opciones de la línea de comandos, ningún otro módulo, función o clase tiene idea de las opciones de la línea de comandos. No hay ningún módulo que requiera 1 de las 5 opciones de configuración. Las clases (o funciones) del módulo tienen argumentos ordinarios y eso es todo.

Solo usamos optparse .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top