Consultas de implementacion del Buffer y sus tests.

[tomi2108]

Buenas! Leyendo los tests que vienen dados en el repositorio me surgen dos dudas. La primera es cuanto control tenemos sobre estos tests? Podriamos modificarlos en base a la implementacion? o deben dejarse tal cual?
La segunda es, dando por hecho que los tests no pueden ser modificados por nosotros y debemos cambiar unicamente los que digan "Completar" (+ agregar nuevos en caso de ser necesarios). No termino de entender los requerimientos de la clase Buffer. Por un lado, este test nos dice que inicialmente maxSize y currentSize son iguales.

  @Test
  void inicialmenteCurrentSizeYMaxSizeCoinciden() {
    Buffer buffer = new Buffer(27);
    Assertions.assertEquals(buffer.getCurrentSize(), buffer.getMaxSize());
  }

Intuitivamente pensaria que currentSize es la cantidad de bytes escrita en el buffer en un determinado momento, por ende empezaria siendo 0, pero supongamos que se hace una excepcion cuando el buffer esta vacio (cuestionable interfaz que dificulta saber si un buffer esta vacio o no solo mirando su currentSize pero ok).
Ahora, el siguiente test nos dice que por mas que no se haya escrito nada en el buffer, el currentSize deberia ser 0 en este caso.

  @Test
  void sePuedeLeerSincronicamenteUnArchivoCuandoNoHayNadaParaLeer() {
    Buffer buffer = new Buffer(100);

    when(lowLevelFileSystem.openFile("ejemplo.txt")).thenReturn(42);
    when(lowLevelFileSystem.syncReadFile(42, buffer.getBytes(), 0, 100)).thenReturn(0);

    File file = fileSystem.open("ejemplo.txt");
    file.read(buffer);

    Assertions.assertEquals(0, buffer.getStart());
    Assertions.assertEquals(-1, buffer.getEnd());
    Assertions.assertEquals(0, buffer.getCurrentSize());
  }

Esto no es contradictorio? O hay algun detalle que no estoy contemplando?

[flbulgarelli]

Buenas! Leyendo los tests que vienen dados en el repositorio me surgen dos dudas. La primera es cuanto control tenemos sobre estos tests? Podriamos modificarlos en base a la implementacion? o deben dejarse tal cual?

No está prohibido que los modifiquen, pero deberían apuntar a mantenerlos sin cambios, salvo que tengan verdaderamente un muy buen motivo: ¿cual sería?

[tomi2108]

No me termina de cerrar la idea de que en dos casos en los que el buffer esta vacio, ya sea porque aun no se ha escrito nada o por que se intento escribir 0 bytes, getCurrentSize devuelva dos valores "semanticamente diferentes" en uno la capacidad maxima del mismo, y en otro 0 representando la ausencia de bytes. Siento que los tests plantean un mismo estado para el buffer, pero esperan respuestas contradictorias, por esto me surge la intencion de modificar el resultado esperado, pero lo seguire meditando.

[flbulgarelli]

Esto no es contradictorio? O hay algun detalle que no estoy contemplando?

En cuanto a esto, no, no es contradictorio y es, por el contrario, intencional.

Las situaciones que se plantean son diferentes:

1. En la primera, inicialmenteCurrentSizeYMaxSizeCoinciden se crea un buffer vacío de 27 bytes. El tamaño máximo y el tamaño actual coinciden, porque no enviaste el mensaje limit, que define cual es el tamaño lógico del buffer. El tamaño físico nunca va a cambiar, porque indica cuánto ocupa en la memoria, mientras que el tamaño lógico lo utilizamos para indicarle a otro componente hasta donde puede escribir (en este caso, hasta su tamaño máximo).
2. En la segunda sePuedeLeerSincronicamenteUnArchivoCuandoNoHayNadaParaLeer, lo que estamos viendo es lo que ocurre cuando se lee un archivo: no sólo se escribe sino que se pone un límite, que se corresponde con hasta donde escribió.

En cualquier caso, ninguno de estos casos plantea la existencia de un buffer "vacío". Los buffer de este problema tienen un tamaño fijo, y se pueden escribir arbitrariamente en cualquier segmento dentro de su tamaño máximo. Además, contamos con punteros que dicen donde inician y terminan los datos.

[tomi2108]

Okey, muchas gracias, me queda clarisimo. Lo estaba pensando como un buffer mucho mas bobo que simplemente acumulaba bytes uno detras de otro.