• El coeficiente de recargo por tarjeta debería aplicarse a la venta y no a cada prenda (a cada una de ellas ya le estás aplicando el recargo del 0.01 de su valor).

Para pensar:

• Si bien la lista de prendas de una venta podría tener objetos repetidos y de esa forma te aseguraste que se puedan pedir por ejemplo "dos sacos nuevos", quizás podrías cosificar este concepto con una nueva entidad Item, que relacione una prenda y la cantidad que se vendió.

• En el cálculo del precio de la prenda, estás de alguna forma asumiendo que todos los estados calculan el precio aplicando un descuento al precio base. ¿Qué pasaría si se inventara un nuevo estado donde el precio no pudiese calcularse en base a restarle un valor al precio base? (Por ejemplo una oferta de precios fijos, como dictaminar que ahora algunos pantalones están de oferta y salen 800 pesos independientemente de su precio anterior).

La carpeta .idea y los archivos .iml no deberían commitearse ni subirse al repo. Podés evitarlo agregandólos al .gitignore.

Deberías tener un archivo por cada clase o interfaz que definas. Si bien es verdad que tecnológicamente es posible definir más de una a la vez y que en un problema chico como este puede no resultar tan molesto, se vuelve difícil de mantener a medida que el sistema crece y también es más complicado para alguien revisar y modificar el código.

Como regla general, desalentamos el uso de la sobrecarga de constructores para modelar los objetos ya que al no tener parámetros nombrados y depende únicamente de su aridad y los tipos podría haber colisiones indeseadas y puede ser un síntoma de un modelado que podría mejorarse.

En tu caso en particular, los constructores te funcionaron como una especie de atajo para crear "valores default" que te sirvieron para testear con mayor facilidad. Por este lado tampoco está muy bueno, porque de alguna manera estás ensuciando el código de dominio con código que es exclusivo para el testeo.

• Estaría bueno que la clase Macowins se llame Negocio, Tienda o algo más general. Esto es más que nada porque en realidad Macowins es "todo el sistema" y no solo esa clase que representa más bien una instancia del negocio, es una cuestión más bien semántica.

• En Java en particular no se utiliza la convención de anteponer una i a las interfaces, directamente podrías llamarlas, por ejemplo, TipoDePago en lugar de ITipoPago.

• Siempre deberías usar modificadores de visibilidad: private para los atributos y public para los métodos y las clases.

• No deberías crear clases adentro de otras clases.

• Cuando instanciás un arrayList, no es necesario explicitar el tipo paramétrico, podés escribir directamente new ArrayList<>() en lugar de new ArrayList<Prenda>().

Cuando comuniques un diseño, lo ideal es que, además del código, incluyas un diagrama de clases.

Además, podés usar prosa si te surge la necesidad de aclarar algo extra, por si hay algo en tu código que pueda resultar complicado de entender o para explicar por qué decidiste ir por una solución en vez de por otra (plantear alternativas).

El hecho de poder tener WKO es algo más bien tecnológico, ya que en Wollok podemos disponer de ellos pero en Java no existe un equivalente directo. Como en Java tenemos la limitante de que para instanciar un objeto debemos crear una clase, lo más similar que tenemos es implementar un Singleton (un patrón de diseño) en el que nos aseguramos de que una clase se instancie una sola vez, de forma que si varios objetos lo conocen están compartiendo la misma instancia. De todas formas, hay que ser cuidadoso al usarlo porque también trae algunas desventajas (por ejemplo podría dificultar el testing) pero eso lo vamos con mayor profundidad durante la cursada.

• En el método realizar venta creás una venta con el valor hardcodeado LocalDate.now(), lo cual dificulta el testing ya que no se puede parametrizar la fecha de creación. Esto es más un comentario general para tenerlo en cuenta, en tu caso particular vi que en los tests justamente no lo usaste porque imagino que te percataste del problema. Quizás para este problema en particular no era tan necesario tener ese método.

• Ojo con los nombres de los tests, es mejor intentar ser descriptivo con lo que hacen teniendo en cuenta el negocio en lugar de enunciar que algo se hace correctamente. Por ejemplo, sería mejor decir algo como elPrecioDeVentaSeReduceALaMitadSiLaPrendaEstaEnLiquidacion en vez de elprecioDeVentaSeCalculaCorrectamenteSiLaPrendaEstaEnLiquidacion.