Mockowanie, co robie zle

Odpowiedz Nowy wątek
2018-06-18 08:37
0

więc mam test który krzaczy się z wiadomościa

Message: Moq.MockException : IHttpClientAdapter.SendAsync(Method: POST, RequestUri: 'https://here.someurl.nl/', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
  Authorization: Basic XXXXXXXXXXXXXX
  Content-Type: application/json; charset=utf-8
}) invocation failed with mock behavior Strict.
All invocations on the mock must have a corresponding setup.

kod

        private Mock<IHttpClientAdapter> mockHttpClientAdapter = new Mock<IHttpClientAdapter>(MockBehavior.Strict);

        [Fact]
        public async void AddDocumentToPackage_SendAsync_ShouldBeCalledWithExpectedValue()
        {
            // Arrange
            var documentForPackage = Builder<DocumentForPackage>.CreateNew().Build();
            var content = documentForPackage.JsonSerialize(jsonSerializerSettings);

            var httpRequestMessage = BuildHttpRequestMessage(content, HttpMethod.Post);

            mockHttpClientAdapter.Setup(x => x.SendAsync(httpRequestMessage));

            var validSignContext = new ValidSignContext(mockHttpClientAdapter.Object);

            // Act
            var result = await validSignContext.AddDocumentToPackage("test", documentForPackage);

            // Assert
            mockHttpClientAdapter.Verify(x => x.SendAsync(httpRequestMessage), Times.Once);
        }

        private HttpRequestMessage BuildHttpRequestMessage(string content, HttpMethod httpMethod)
        {
            var httpRequestMessage = new HttpRequestMessage();
            httpRequestMessage.Headers.Add("Authorization", "Basic XXXXXXXXXXXXXX==");
            httpRequestMessage.Content = new StringContent(content, Encoding.UTF8, "application/json");
            httpRequestMessage.Content.Headers.Add(@"Content-Length", content.Length.ToString());
            httpRequestMessage.RequestUri = new Uri("https://https://here.someurl.nl/");
            httpRequestMessage.Method = httpMethod;
            return httpRequestMessage;
        }

Interfejs do adaptera

    public interface IHttpClientAdapter
    {
        Task<HttpResponseMessage> SendAsync(HttpRequestMessage request);
    }

metode którą staram się przetestować

        public async Task<DocumentForPackageResponse> AddDocumentToPackage(string packageId, DocumentForPackage documentForPackage)
        {
            var request = new HttpRequestMessage(HttpMethod.Post, new Uri(baseUrl + "packages/" + packageId + "/documents"));
            request.Headers.Add(authorizationHeaderName, authorizationHeaderValue);
            request.Content = new StringContent(documentForPackage.JsonSerialize(jsonSerializerSettings), Encoding.UTF8, "application/json");

            var response = await httpClient.SendAsync(request);
            return await response.Content.ReadAsAsync<DocumentForPackageResponse>();
        }

jezeli usunę

httpRequestMessage.Content.Headers.Add(@"Content-Length", content.Length.ToString());

nie za bardzo pomaga, to juz jest kod który przeszedł z 4-5 modyfikacji (probówałem doprowadzić do działajacego rezultatu)

i problem mam z wiekszoscia funkcji w tej klasie, nawet jak zrobie setup gdzie jest It.IsAny<> a mock ma normalne zachowanie to pokazuje NPRE mimo, ze... nie powinno?

edytowany 6x, ostatnio: fasadin, 2018-06-18 08:56

Pozostało 580 znaków

2018-06-18 08:58
0

Na moje oko to masz niepełny setup.

mockHttpClientAdapter.Setup(x => x.SendAsync(httpRequestMessage)).ReturnsAsync(<<jakiś obiekt>>);

edit:

ustaw behaviour na loose, a w setupie zrób tak:

mockHttpClientAdapter.Setup(x => x.SendAsync(httpRequestMessage)).ReturnsAsync(new HttpResponseMessage{Content = "content"});

jeśli to nie pomoże, to "na pewno bug w kompilatorze" ;P

edytowany 1x, ostatnio: john_klamka, 2018-06-18 09:17
Pokaż pozostałe 5 komentarzy
zwracam nie null, przeciez sam napisales zebym zrobil ReturnsAsync(<<jakiś obiekt>>); i to zrobilem, ale jak mam konkretny setup z konkretnymi parametrami, to ten setup jest jakos nieprawidlowy bo nie jest zmockowany - fasadin 2018-06-18 09:12
czekaj, response jest null? czy response.Content? bo jakoś nie widzę możliwości, żeby przy takim setupie wywalał nulla z await httpClient.SendAsync(request); - john_klamka 2018-06-18 09:14
jezeli zostawie wszystko tak jak jest (tylko dodam Twoj kod) to response jest nullem, gdy tam mu It.IsAny() wtedy zwraca obiekt i jest ok, ale ja chce dla konkretnego argumentu to wywolac a nie dla wszystkich ;) - fasadin 2018-06-18 09:17
no dobra, to w takim razie jak BuildHttpRequestMessage() działa? może tam coś nie tak jest inicjalizowane? - john_klamka 2018-06-18 09:19
w pierwszym poscie masz - fasadin 2018-06-18 09:21

Pozostało 580 znaków

2018-06-18 09:44

Dobra, musiałem wypić kawę żeby to przetrawić. W setupie dajesz httpRequestMessage, który jest wynikiem metody BuildHttpRequestMessage();

var httpRequestMessage = BuildHttpRequestMessage(content, HttpMethod.Post);

mockHttpClientAdapter.Setup(x => x.SendAsync(httpRequestMessage));

Natomiast w testowanej metodzie AddDocumentToPackage() przekazujesz mu request stworzony w tej metodzie, a nie ten z setupu:

var request = new HttpRequestMessage(HttpMethod.Post, new Uri(baseUrl + "packages/" + packageId + "/documents"));
(...)
var response = await httpClient.SendAsync(request);

A do tego masz Strict behaviour i ponieważ nie było inwokacji z setupa to Moq się burzy ;)

edit:
Dlatego też, jeśli zmienisz behaviour na loose, to zwraca Ci null - bo nie było setupu dla tego requesta.

edytowany 2x, ostatnio: john_klamka, 2018-06-18 09:45
... widze dzieki - fasadin 2018-06-18 09:51
jak pisalem test to myslalem, ze on porowna po prostu wartosci a nie referencje - fasadin 2018-06-18 09:54
jak chcesz żeby porównał wartości, to sobie skorzystaj z It.Is<httprequestmessage>(m => m.Content == "asdf" && m.Headers == "asdasd" itp itp) - john_klamka 2018-06-18 09:55
tak wlasnie pisze :) dzieki - fasadin 2018-06-18 09:56
zrobilem troche inaczej, nie chcialo mi sie recznie porownywac parametrow ani nie robic strasznie duzego jednego assera - fasadin 2018-06-18 11:38

Pozostało 580 znaków

2018-06-18 11:36
2

dla potomnych. Pozbylem sie strict (jako, ze sprawdza referencje do obiektu) i zrobilem reczne sprawdzanie parametrow

        [Fact]
        public async void AddDocumentToPackage_SendAsync_ShouldBeCalledWithExpectedValue()
        {
            // Arrange
            var documentForPackage = Builder<DocumentForPackage>.CreateNew().Build();
            var content = documentForPackage.JsonSerialize(jsonSerializerSettings);
            var dummyResponse = Builder<DocumentForPackageResponse>.CreateNew().Build();
            var packageId = "test";
            var uri = new Uri(baseUrl + "packages/" + packageId + "/documents");

            var httpRequestMessage = BuildHttpRequestMessageForPost(content, HttpMethod.Post, uri);

            var returnValue = Builder<HttpResponseMessage>.CreateNew()
                .With(x => x.Content = new StringContent(dummyResponse.JsonSerialize(), Encoding.UTF8, "application/json"))
                .Build();

            HttpRequestMessage callback = null;

            mockHttpClientAdapter.Setup(x => x.SendAsync(It.IsAny<HttpRequestMessage>())).ReturnsAsync(returnValue).Callback<HttpRequestMessage>(y => callback = y);

            var validSignContext = new ValidSignContext(mockHttpClientAdapter.Object);

            // Act
            var result = await validSignContext.AddDocumentToPackage("test", documentForPackage);

            // Assert
            mockHttpClientAdapter.Verify(x => x.SendAsync(It.IsAny<HttpRequestMessage>()), Times.Once);
            callback.Content.Should().BeEquivalentTo(stringContent);
            callback.RequestUri.Should().BeEquivalentTo(uri);
            callback.Headers.Should().BeEquivalentTo(httpRequestHeaders);
        }
edytowany 1x, ostatnio: fasadin, 2018-06-18 11:37

Pozostało 580 znaków

2018-06-19 10:17
0
    public interface IHttpClientAdapter
    {
        Task<string> SendAsync(string request);
    }

    class ValidSignContext
    {
        private readonly IHttpClientAdapter httpClient;

        public ValidSignContext(IHttpClientAdapter httpClient, string bleble)
        {
            this.httpClient = httpClient;
        }

        public async Task<string> AddDocumentToPackage(string packageId, string documentForPackage)
        {
            var request = $"{documentForPackage} Ble Ble Ble";

            var response = await httpClient.SendAsync(request);

            return "ble ble ble";
        }
    }
public class FakeHttpClientAdapter : IHttpClientAdapter
    {
        public string RecivedOjbect { get; set; }

        public async Task<string> SendAsync(string request)
        {
            RecivedOjbect = request;
            return await Task.Run(() => string.Empty);
        }
    }

Frameworki mają ułatwiać życie, a nie utrudniać. Zobacz o ile mój test jest czytelniejszy od twojego. Jak sądzisz, czy twój test jest odporny na zmiany w kodzie.?

    [TestFixture]
    public class Class1
    {
        [Test]
        public async Task AddDocumentToPackage_SendAsync_ShouldBeCalledWithExpectedValue()
        {
            var httpRequestMessage = "test";
            var clientAdapterMock = new FakeHttpClientAdapter();

            await AddDocumentToPackage(clientAdapterMock, httpRequestMessage);
            var expectedObject = BuildHttpRequestMessage();

            Assert.AreEqual(expectedObject, actual: clientAdapterMock.RecivedOjbect);
        }

        //
        //
        //

        private string BuildHttpRequestMessage()
        {
            var yoursLongBuild = "test Ble Ble Ble";
            return yoursLongBuild;
        }

        private Task<string> AddDocumentToPackage(IHttpClientAdapter mock, string httpRequestMessage) =>
            new ValidSignContext(mock, "stub").AddDocumentToPackage("stub", httpRequestMessage);
    }
edytowany 1x, ostatnio: Enter Name, 2018-06-19 10:27

Pozostało 580 znaków

2018-06-19 10:25
0
public async Task<string> AddDocumentToPackage(string packageId, string documentForPackage)

no super, ale

  • zmieniles argument na string. A documentForPackage jest bardzo zlozonym obiektem
  • nie dodajesz odpowiednich headerow i request nawet sie nie wykona (dostaniesz 401)
  • nie masz contentu wiec w sumie nic nie wyslesz (bo tak zbudowane jest API z ktorym sie komunikuje)
  • Przeniosles implementacje na adapter, nie chce miec w adapterze logiki, to ma byc prosty adapter a nie posiadac biznesowa logike

moze jest czytelniejszy, ale nie spelnia wymagan by dzialal. Oraz jest kod ktory jest uzywany tylko do testow.

a na jakie konkretne zmiany w kodzie moj kod nie jest przygotowany?

masz FakeHttpClientAdapter tylko do testowania. takze masz kod w repo ktory jest uzywany tylko do testow. Wiec co testujesz tak na dobra sprawe? Klase ktora napisales do testow? Bo Taki mock imo nie ma sensu (cytujac Ciebie Frameworki mają ułatwiać życie, a nie utrudniać) wiec czemu nie uzyjesz Moq?

edytowany 4x, ostatnio: fasadin, 2018-06-19 10:27

Pozostało 580 znaków

2018-06-19 10:33
0

Nie chciało mi się tego implementować, to jest jedynie przykład. Nie użyłem, bo mi przeszkadzał. Test miał sprawdzić, czy mock dostaje obiekt, który jest generowany w metodzie i to właśnie zrobił.

Pokaż pozostałe 13 komentarzy
Masz, rację, ale nie wszystko tak zamokujesz, zwłaszcza jakieś zewnętrzne biblioteki. Moq mi się nie podoba wydaje się strasznie nieczytelny. Ja na przykład preferuje robić sobie implementacje repositoryInMemory. Zamiast frameworkiem to konfigurować, wydaje mi się to czytelniejsze. - Enter Name 2018-06-19 11:56
ale nie wszystko tak zamokujesz zgadzam sie, dlatego stworzylem adapter by moc mockowac te rzeczy które normalnie nie moge mockowac ;) Dla mnie mocku jest czytelny, to juz jest wlasna opinia. Wiadomo kazdy moze inaczej widzec ten kod ;) - fasadin 2018-06-19 11:58
haha... Najlepiej to zrobić jeden integracyjny test oczami. ;) - Enter Name 2018-06-19 12:03
Jak masz generyczną metodę, to jak ją w sensowny sposób testujesz bez napisania dodatkowego kodu dla testu.? Nie, żebym się czepia jakości twojego testu. Po prostu jestem ciekawy. - Enter Name 2018-06-20 21:36
jak mam generyczną metodę to jest wyspecjalizowaną na dany interfejs i wtedy testuje generyczny kod na bazie interfejsu/klasy. Jezeli dochodzi nowy kod (override) to wtedy testuje ten nowy kod. A odnosnie tego kawalku kodu masz racje ze nie jest super jakosci. Bede patrzyl czy moge uzyc HttpClientFactory, jezeli nie to i tak wyniose gdzies kod ktory sie potwarza - fasadin 2018-06-20 21:53

Pozostało 580 znaków

2018-06-19 10:40
0

var result = await validSignContext.AddDocumentToPackage("test", documentForPackage);

Ja bym nie zostawiał tego w teście no, chyba że masz tylko jeden test z tą metodą.

ale dlaczego? Jaki jest tego powod ze bys nie zostawial tego? Mam dwa testy do tej metody bo wiecej nie trzeba (nie ma wiecej co testowac) - fasadin 2018-06-19 10:42
No ja wolę, refaktoryzować metodę fabrykującą niż testy. To ma pomagać, oczywiście nie jest to obowiązek, zwracam uwagę, że może to spowodować później problem, lecz nie musi. - Enter Name 2018-06-19 10:45
zwracam uwagę, że może to spowodować później problem JAKI. Nigdzie nie napisales jaki problem. No ja wolę, refaktoryzować metodę fabrykującą niż testy Czyli zmieniasz kod i testy nadal przechodza? To na pewno zle sa napisane testy skoro zmieniasz logike i test sprawdzajacy ta logike przechodzi po zmianach to na pewno cos jest nie tak. Jezeli zmieniasz cos w mockach (oprocz definicji) to zawsze powinno dzialac (przy unit testach) i u mnie tak bedzie to dzialac. Nadal nie podales konkretnego przykladu - fasadin 2018-06-19 10:47
Masz napisane w komentarzu na górze ;) - Enter Name 2018-06-19 10:53

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0