#7058 LeftMenu vitest #1153
No reviewers
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: verdnatura/salix-front#1153
Loading…
Reference in New Issue
No description provided.
Delete Branch "7058_leftMenu_vitest"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hay 3 skip todavia
WIP: #7058 LeftMenu vitestto #7058 LeftMenu vitest@ -35,1 +35,4 @@
const filteredItems = computed(() => {
return filterItems();
});
function filterItems() {
Solo se usa 1 vez
Lo sé, era la manera mas simple de probar la lógica de esa función.
Esto no debería haber subido así porque no haría falta poner las llaves y el return
Si no hay manera de poder testearlo vale, pero si se puede mejor poner dentro de computed, si se vuelve muy complicado quizá sería mejor testearlo con test unitario con cypress
Yo haría el test en un unitario con cypress. Queda feo crear una fn que solo vas a usar 1 vez y es simple.
He vuelto a probar y me ha funcionado dejandolo dentro del computed.
No se que pasó
@ -73,0 +166,4 @@
expect(getMethodB).not.toHaveBeenCalled();
});
it('should call getMethodA when source is main', () => {
Poner otro nombre, está repetido.
oh vaya
should not call getMethodA when method is undefined por ej.
@ -93,0 +348,4 @@
vi.clearAllMocks();
});
it('should add menu items to parent if matches are found', () => {
Aquí habría que comprobar que el módulo ha sido añadido no?
Eso correspondería al test de useNavigationStore, no? No podríamos ni deberíamos testear funcionalidad de otros archivos
En el título del archivo pone should add menu items. Como sabes que ha funcionado? solo sabes que se ha llamado a la función. Los 3 tests son exactamente iguales, con diferente título. Veo tu punto, si no crees que sea el lugar de testearlo, cambia el título del test por uno que compruebe realmente lo que hace esa función, llamar a otra función.
Mmm...WTF.
Lo reviso, pero si 3 iguales
Hacer solo 1 test que compruebe que la función ha sido llamada. Estos tests hay hacerlos en navigationStore según lo que hablamos en persona.
@ -93,0 +323,4 @@
});
});
describe('addChildren', () => {
En estos tests, solo veo que compruebes que la función haya sido llamada, no se debería comprobar si navigation ha cambiado?
El test no comprueba que se ha añadido el item, solo que la función addMenuItem ha sido llamada. Quitar test y comprobar si se han añadido en los tests de useNavigationStore.
@ -73,0 +194,4 @@
});
it('should filter items based on search input', async () => {
vm.search = 'Rou';
Estaría bien crear un test que devuelva algún resultado, mockea otra para comprobar que solo te va a devolver esa.
He usado cust para que compruebe customer
.
@ -0,0 +55,4 @@
describe('useNavigationStore', () => {
beforeEach(() => {
setActivePinia(createPinia());
Si lo dejas aquí OK
Si lo mueves a beforeAll, tienes dependencia de los casos de prueba y fallan
@ -93,0 +328,4 @@
expect(vm.normalize(input)).toBe(expected);
});
});
// describe('addMenuItem', () => {
Quitar
OMG
@ -0,0 +104,4 @@
expect(store.pinnedModules).toEqual(['order']);
});
it('should add menu item correctly', () => {
yo comprobaría tambien que se ha añadido en el parent
Vaya, no lo veía importante, pero tras hacer unas pruebas, si que lo es
.