Whilst Doc Browns answer is a perfectly valid approach and will solve your problem, I would strongly suggest that you investigate using an approach that uses Command and Query objects rather than using the repository pattern.

The repository pattern suffers from issues around changes as every time you need a different query you have to add a new method to your repository interface, where as having Command and Query objects as first class citizens in your project means you can just add a new class when you need a new query and you don’t have to change any exist code. It also means that when you want to apply cross cutting concerns (like logging) to your queries/commands then you can do it in a single place and wrap your command/queries in the logging wrapper.

You could implement it along these lines:

You could have a query class like:

public class GetAllMovieReviewsQuery : IQuery<IEnumerable<MovieReview>>
{
     public GetAllMoveReviewsQuery(int movieId)
     {
          MovieId = movieId;
     }

     public int MovieId{get;private set;}
}

This is simple and just collects the parameters it needs through its constructor, and declares the type of the return value of the query.

And then a handler for that query which actually queries the db:

public class GetAllMovieReviesQueryHandler : IQueryHandler<GetAllMoveReviewsQuery, IEnumerable<MovieReview>>
{
      private DbContext movieDbContext;

      public GetAllMovieReviesQueryHandler(DbContext movieDbContext)
      { 
           this.movieDbContext = movieDbContext;
      }

      public IEnumerable<MovieReview> Execute(GetAllMoveReviewsQuery query)
      {
           return dbContext.MovieReviews.Where(x=>x.MovieId == query.MovieId).ToList();
      }
}

then in your controller you inject an object which knows how to find the handler for any given query/command (basically a dictionary of the type of a query/command to the handler instance for that query command) and just call this

  class MyReviewController
  {
       public MyReviewController(IQueryDispatcher dispatcher)
       {
       }

       public IEnumerable<MovieReview> GetReviewsFromMovie(int movieId)
       {
            var query = new GetAllMovieReviewsQuery(movieId);
            return dispatcher.Execute(query);
       }
  }

This also has the advantage that you can have different sources for individual queries, by simply replacing the handler which handles that query with one that looks up the answer in a web service or whatever.

To then unit test this you could simply replace the IQueryDispatcher in the controller with a mocked instance which returns the values to test with when given a particular query.

This is an excellent place to start reading and also covers a fair bit about DI, but there are others who also think that the repository pattern has had its day and is more trouble than its worth

For such a requirement, you can use a MovieReviewsRepository class with an interface IMovieReviewsRepository:

 interface IMovieReviewsRepository
 {
      IEnumerable<MovieReview> GetAllReviews(int movieID);
 }

In your controller, you can inject an IMovieReviewsRepository object through the constructor:

 class MyReviewController
 {
       public MyReviewController(IMovieReviewsRepository repository)
       {
       }
 }

Now you are free to implement the interface by a class MovieReviewsRepository providing the objects from a database, or by a class MovieReviewsRepositoryMock providing, for example, some hardcoded test data without any database access. This will make real unit testing possible. But it will also allow to exchange the source of your “movie review objects” to something completely different like a web service or a file without changing the controller, just by providing different IMovieReviewsRepository implementations

Of course, this approach could be generalized to lots of your model classes by making your repository a generic class, like it is shown here.