Implementando preguntas de tipo Choice

Hoy he dejado los tests a un lado, ya que he decidido implementar primero aquellos tipos de preguntas que según la encuesta más útiles son para los profesores, estas son: extended_text, choice, choice_multiple y text_entry, en realidad las tres primeras son las que claramente más útiles han manifiestado los profesores que lo son. Así que me he metido con Glade, a diseña la interfaz para crear las preguntas de tipo elección con una o varias respuestas, he cambiado algunas cosas de la interfaz que cree de prueba, para adaptarla con el interés de cumplir la especificación IMS QTI v2.0.

Luego ya en Python, ha tocado programar los eventos, realmente sólo tres (tres “clicks” de botones) para ampliar el formulario para disponer de espacio para especificar más respuestas posibles, hay tres espacios por defecto, para crear la pregunta y para cancelar. Para terminar de pasar los tests, he tenido que crear una función para comprobar que el formulario se ha rellenado de forma correcta y otra para crear el fichero XML de la pregunta.

Obtenido: Implementación y creación de la interfaz para la preguntas de tipo choice.

Objetivo: Continuar con la creación de interfaces e implementación para las preguntas

Testing: in_line_choice

De este tipo de preguntas ya comenté algo en el anterior post, son aquellas que se visualizan como preguntas en las que se da un texto y en diversos puntos de este texto se ha de elegir una respuesta de una serie de opciones que se le da al alumno. Una forma de representación de este tipo de preguntas es mostrar el texto y en aquellos puntos donde se debe elegir una respuesta, presentar un combobox cuyos elementos son las distintas opciones de las que dispone el alumno para elegir.

A efectos de test, la función de comprobación de que la pregunta se creo de forma correcta es igual que la función de comprobación de una interacción text_entry, a excepción que no se debe indicar una longitud máxima para la respuesta (ya que ya viene presentada por el profesor). En cuanto a la creación del documento XML, se ha indicar la respuesta correcta y mapear cada una de las respuestas con un valor, esto se realiza mediante los nodos mapEntry, las opciones que se van a mostrar se indican mediante nodos inlinechoice a las que se les asigna un identificador que es usado en el mapeo de respuesta – calificación (el nodo mapEntry que comentaba), dentro de los nodos inlinechoiceInteraction que es el nodo representativo de este tipo de preguntas.

Obtenido: Test ha cumplir por las preguntas in_line_choice

Objetivo: Comenzar a implementar las preguntas básicas que satisfacen los tests creados durante estos días.

Testing: Text_entry

Para el test de este tipo de preguntas, será de forma muy similar a choice_multiple. Se trata de verificar que el método que comprueba las entradas realizadas por el usuario en la GUI, son correctas. En este caso, será de forma similar a los tipos de preguntas choice_multiple, y habrá un campo específico para decir la longitud de la respuesta que se espera. Además, será necesario introducir una marca en la pregunta para saber donde irá el “hueco en blanco”.

He estado revisando algunos LMS, y he visto, que estas preguntas se editan totalmente a mano, es decir, no se dispone de interfaz gráfica y uno ha de conocer por ejemplo, “el lenguaje de moodle”, para sus preguntas tipo cloze, este sería un ejemplo de como escribir un hueco en blanco esperando una respuesta del alumno{1:SHORTANSWER:Wrong answer#Feedback for this wrong answer~=Correct answer#Feedback for correct answer~%50%Answer that gives half the credit#Feedback for half credit answer} En el caso de Moodle, se puede insertar en este tipo de preguntas, no sólo el hueco para la respuesta libre del alumno, sino también se puede insertar una lista desplegable (un combobox) con respuestas posibles. Según el estándar IMS QTI v2.0, si se inserta un combobox ya serían interacciones del tipo in_line_choice, además el hecho de conocer un lenguaje, en mi opinión, si se puede evitar al usuario mejor.

El estilo de Claroline para crear estas preguntas me gusta más, en concreto para indiciar donde se ha de poner el espacio en blanco insertando simplemente [] . Así, que he optado por crearlas a partir de ese mismo símbolo. En el testing eso se traduce, en que el método de comprobación, ha de validar que exista ese símblo de forma exacta, se intrepta que se ha querido utilizar ese símbolo si se intruduce texto entre los corchetes.

Por último, habrá que realizar la comprobación de que los nodos del documento XML se han creado con los valores correctos.

Obtenido: Tests para las preguntas text_entry

Objetivo: Realizar algún tests más y comenzar con la implementación que cumplan los tests creados.

Testing: Choice_multiple

En este caso se trata de realizar los tests para el tipo de interacción choice_multiple, es decir, preguntas con elección múltiple y respuesta múltiple (1 o más pueden ser correctas). Los métodos de prueba son muy parecidos al test para la interacción de tipo ensayo, ya que el método de comprobar es básicamente igual, añadiendo que esta vez, tiene que comprobar que se han creado respuestas posibles para la pregunta, que se les ha asignado un identificador, una respuesta y una calificación a cada una de ellas y estas son correctas (son texto y la calificación es un número). En este caso, la comprobación del método que modifica el archivo XML plantilla requiere más condiciones y por último también se hace necesario disponer de un botón u otro mecanimo que genere la opción de insertar más respuestas, ya que la presentación inicial de la interfaz ofrecerá la posibilidad de introducir tres respuestas. Por lo tanto, otro método consiste en comprobar que la interfaz se modificó de forma adecudada para dar la posibilidad de introducir más respuestas.

Obtenido: Tests para las preguntas choice_multiple.

Objetivo: Más tests!

Testing: text_extended

En principio la interfaz para este tipo de interacciones es la más sencilla, ya que de forma común, son las preguntas de ensayo o a desarrollar. A la hora de crear un test, importamos unittest, la clase a testear y aquellas otras que nos hagan faltan a la hora de crear los tests y la clase de test que creamos hacemos que herede de unittest.TestCase. La interfaz tendrá que tener un método de comprobar aquellos datos que son introducidos, así como la de crear el documento XML de la interacción creada. Como se necesita una instancia de la clase ExtenedText, en el método set_up() (que se ejecuta antes de ejecutar cada test), creo esa instancia.

Los métodos creados consisten en introducir datos erróneos o dejar campos en blanco y verificar que el método que se crea para tal efecto devuelve False (cuando no es correcto) y también probando con datos correctos, que efectivamente devuelve True.

Por último, comprobar que la plantilla XML que se modifica mediante la interfaz (se tiene un archivo plantilla que se modifica o completa, según los datos introducidos del usuario, con el fin de no tener que crear todo el XML, ya que hay datos que son constantes para un tipo de interacción dada) , se realiza de forma correcta. Se comprueba que los campos toman los valores esperados mediante el método assertEqual.

Para poder ejecutarlo al final del archivo podemos optar por:

if __name__ =' __main__' :
unittest.main()

o bien por:

suite = unittest.TestLoader().loadTestsFromTestCase(TestchoiceMultiple)
unittest.TextTestRunner(verbosity=2).run(suite)

Obtenido: Test para las preguntas text_extended

Objetivo: Seguir creando tests para el resto de preguntas.

Testing: Editor

Hoy he comenzado a crear unos tests para el editor de preguntas que debe superar. Me ha servido para recordar cosas de Python y para aprender otras nuevas. He empezado con las funciones más fáciles, aquellas de modificar la fuente a negrita, cursiva, subrayada. Los tests simulan la creación de que hay un texto en el textbuffer del editor y es seleccionado y posteriormente pulsado uno de los diferentes botones. Por lo tanto se ha de comprobar que el texto seleccionado tiene el tag correspondiente que el botón debe aplicar. Ya que el pensamiento es utilizar toggledButton, es decir, botones de estado, además, cuando se entra en una región que tiene una etiqueta esté botón se ha mostrar en estado pulsado y desactivado si no en la posición del cursor no se encuentra la marca de ese botón. Por último, también tiene que a partir de un texto que tiene una etiqueda puesta, si se selecciona el texto y se desactiva el botón pertinente, el tag del texto seleccionado debe desaparecer.

Obtenido: Creación algunos métodos de tests para el editor.

Objetivo: Trabajo con los colores de las fuentes.