Od wczoraj dostępny jest pakiet, który umożliwia łatwe zamockowanie DbSet<TEntity> wykorzystując Moq. Źródła oraz krótką instrukcję można znaleźć na portalu GitHub. Natomiast wersję skompilowaną można ściągnąć z portalu NuGet. Zasada działania jest taka sama jak w przypadku pakietu Moq.EntityFramework.Helpers.
Największą zaletą Azure Functions jest skrócenie czasu, który jest potrzebny do wypuszczenia produktu na rynek. Można je również zastosować w celu przyspieszenia prototypowania aplikacji. Od jakiegoś czasu można zdefiniować mocka naszej funkcji, który w odpowiedzi na wysłane zapytanie pod konkretne API wyśle nam ustaloną odpowiedź. Rozwiązanie to ma olbrzymi potencjał. W szczególności w przypadku różnego rodzaju prototypowania aplikacji. Wystarczy tylko zdefiniować nasz end point i wskazać jaka odpowiedź ma zostać zwrócona. Dzięki temu możemy budować od razu docelowe powiązania w naszej aplikacji. A w późniejszym etapie pracy po prostu zastąpić definicję mocka poprawnie zaimplementowaną funkcją. Funkcjonalność ta umożliwia również zoptymalizowanie [...]
Na blogu pojawiły się ostatnio dwa wpisy pokazujące w jaki sposób mnożna zamockować DbSet<TEntity> wykorzystując Moq: wywołania synchroniczne – Mockowanie typów DbContext oraz DbSet z wykorzystaniem Moq wywołania asynchroniczne – EntityFramework – testowanie zapytań asynchonicznych Opisane rozwiązania połączyłem w jednej bibliotece i opublikowałem jako pakiet NuGet – Moq.EntityFramework.Helpers. […]
Jakiś czas temu opisałem w jaki sposób można zamockować typy DbContext przy pomocy Moq – Mockowanie typów DbContext oraz DbSet z wykorzystaniem Moq. Temat ten nie został wtedy całkowicie wyczerpany. Pozostał jeden element do opisania – zapytania asynchoroniczne. Do tego elementu chciałbym dziś wrócić. Punktem wyjścia będzie poprzedni wpis – czyli mamy fragment kodu, który pozwala na zamockowanie DbSet<T>. Teraz tylko dodamy możliwość obsługi wywołań asynchronicznych. Aby to zrobić należy zaimplementować interfejs IDbAsyncQueryProvider: public class InMemoryAsyncQueryProvider<TEntity> : IDbAsyncQueryProvider { private readonly IQueryProvider innerQueryProvider; internal InMemoryAsyncQueryProvider(IQueryProvider innerQueryProvider) { this.innerQueryProvider = innerQueryProvider; } public IQueryable CreateQuery(Expression expression) { return new InMemeoryAsyncEnumerable<TEntity>(expression); } public IQueryable<TElement> CreateQuery<TElement>(Expression expression) { return new InMemeoryAsyncEnumerable<TElement>(expression); } public object Execute(Expression expression) { return this.innerQueryProvider.Execute(expression); } public TResult Execute<TResult>(Expression expression) { return this.innerQueryProvider.Execute<TResult>(expression); } public Task<object> ExecuteAsync(Expression expression, CancellationToken cancellationToken) { return Task.FromResult(Execute(expression)); [...]
Pisząc testy jednostkowe w aplikacjach, które przechowują dane w bazie danych prędzej, czy później będziemy zmuszeni do odizolowania warstwy dostępu do bazy danych. W opisywanym przypadku jako ORM wykorzystywany jest Entity Framework. Kod definiujący podstawowe elementy wygląda w następujący sposób: public class User { public int Id { get; set; } public string Login { get; set; } public string Name { get; set; } public string Surname { get; set; } public bool AccountLocked { get; set; } public virtual List<Role> Roles { get; set; } } public class UsersContext : DbContext { public virtual DbSet<User> Users { [...]
