Return to Revisions

Welcome to code review and thanks for sharing your code.

When writing UnitTests keep in mind that they are documentation. Test code has less restrictions for identifier names. This means that method names are usually longer and you should not "shorten" your unit test methods.

1. The test name should describe the expected behavior in detail

    @Test
    public void getAllVideos_returnsCompleteListFromRepository() throws Exception{ 
        // ...
   

2. A unit test always has three parts: arrange, act and assert. You should always have this three parts visible in your test methods.

In your example you do the act part implicitly in the assert line. This prevents you from introducing variable that could give useful information about the result:

    @Test
    public void getAllVideos_returnsCompleteListFromRepository()
        // arrange 
        List<Video> allVideosInRepository = new ArrayList<>();
        when(videoRepository.findAll()).thenReturn(new ArrayList<Video>());
        // act
        List<> allVideosFromRepository = videoService.getAllVideos();
        // assert
        assertEquals(allVideosInRepository, allVideosFromRepository, "tested");
    }

For the same reason the String parameter of the assert* method should always be a useful hint in case the test fails because it is part of the error message:

        assertEquals(allVideosInRepository,
                     allVideosFromRepository,
                     "is same object");

I feel like i just compare the same mock values ArrayList of Video and what's the point of doing this or i just do it wrong way.

This is not a problem of your unit tests but of your current design.

For the time being your VideoService class is nothing more than a facade to a Collection, there is no business behavior (yet) to be tested.