Czy moje testy jednostkowe są dobre?

0

Hej, wciąż się uczę pisania testów jednostkowych, dlatego będę wdzięczny za wszelkie uwagi i konstruktywną krytykę mojego kodu, zanim się zabiorę za testowanie kolejnych klas. Ciekaw jestem czy coś byście zrobili inaczej lub dołożyli. Wykorzystuję xUnit, **Moq **i Prism.Core.

Z racji objętości kodu zdecydowałem się jedynie umieścić link do GitHub moich testów.

A tutaj jest link do testowanej klasy modelu widoku.

Z góry dziękuję!

1

Też ostatnio trochę piszę testów ale czy takie mają sens?

[Fact]
        public void CommandCompletedControlsSetup_Called_ResetsAllItsVisibiliProperties()
        {
            _viewModel.UpdateStatusBar = 1;
            _viewModel.VisibilityStatusBar = true;
            _viewModel.ProgressDisplay = "some txt";
            _viewModel.WorkStatus = "some txt";
            _viewModel.VisibilityCancellingMsg = false;
            _viewModel.VisibilityCancelTestingBtn = true;
            _viewModel.VisibilityTestingBtn = false;
            _viewModel.VisibilityCancelUpdatingBtn = true;
            _viewModel.VisibilityUpdatingBtn = false;

            _viewModel.CommandCompletedControlsSetup();

            _viewModel.UpdateStatusBar = 0;
            _viewModel.VisibilityStatusBar = false;
            _viewModel.ProgressDisplay = "";
            _viewModel.WorkStatus = "";
            _viewModel.VisibilityCancellingMsg = true;
            _viewModel.VisibilityCancelTestingBtn = false;
            _viewModel.VisibilityTestingBtn = true;
            _viewModel.VisibilityCancelUpdatingBtn = false;
            _viewModel.VisibilityUpdatingBtn = true;
        }

        [Fact]
        public void ResetControls_Called_ResetsAllItsVisibiliProperties()
        {
            _viewModel.AllControlsEnabled = false;
            _viewModel.VisibilityCancellingMsg = true;

            _viewModel.ResetControls();

            _viewModel.AllControlsEnabled = true;
            _viewModel.VisibilityCancellingMsg = false;
        }
2

Tak na szybko to zwróciłbym uwagę na nazewnictwo testów:
PopulateLists_PopulatesLists - masło maślane :)
Tak aby nazwa testu wprost pokazywała twoje zamiary: w jakim stanie jest system -> co wykonujesz -> jaki rezultat oczekujesz.
Konwencji nazewniczych jest sporo. Wybierz odpowiednią dla siebie, teamu, projetu
https://dzone.com/articles/7-popular-unit-test-naming

1

Ja chyba nie rozumiem takiego testu - ustawiasz pewne cechy ViewModelu, uruchamiasz na nim pewną metodę, ustawiasz cechy ponownie. A gdzie sprawdzenie czegokolwiek?

0

Btw., testuję metody które mają resetować kilka własności i generalnie to test się sprowadza do wylistowania ich, odpalenia metody i asertowania tych własności, jak niżej:

public class ComputeServiceTests
    {
        private ComputeService _serviceClass;
        public ComputeServiceTests()
        {
            _serviceClass = new ComputeService();
        }

        [Fact]
        public void ResetComputeVariables_UpdatesProperties()
        {
            _serviceClass.DictValue = 10;
            _serviceClass.FinalResult = 10;
            _serviceClass.Result = 10;
            _serviceClass.SiblingIndex = 10;
            _serviceClass.Counter = 10;
            _serviceClass.ChildFromList = null;

            _serviceClass.ResetComputeVariables();

            Assert.Equal(1, _serviceClass.DictValue);
            Assert.Equal(0, _serviceClass.FinalResult);
            Assert.Equal(0, _serviceClass.Result);
            Assert.Equal(0, _serviceClass.SiblingIndex);
            Assert.Equal(0, _serviceClass.Counter);
            Assert.NotNull(_serviceClass.ChildFromList);
        }
    }

Czy da się to zrobić jakoś bardziej elegancko?

A poniżej SUT:

/// <summary>
        /// resets properties used in various methods
        /// </summary>
        public void ResetComputeVariables()
        {
            DictValue = 1;
            FinalResult = 0;
            Result = 0;
            SiblingIndex = 0;
            Counter = 0;
            ChildFromList = new LoadedHorse();
        }
1

Możesz użyć FluentAssertions i tam będziesz mógł to zrobić jedną linijką w stylu: _serviceClass.ShouldBeEquivalentTo(_expected).
Tak ogólnie, to nie jestem pewien, czy warto pisać takie testy do GUI.

1

@bakunet:

Do testowania widoku służą testy akceptacyjne, a nie jednostkowe.

To, co powinieneś przetestować jednostkowo to wewnętrzne składniki (jednostki) domeny ewentualnie jakieś utilsy.

No ale u ciebie za bardzo się nie da skoro jedna funkcja ma grubo około 300 lini.

0

Pomijając wzorce, nazewnictwo, to unit testy mają testować (nietrywialną) logikę aplikacyjną w najmniejszych sensownych jednostkach operacyjnych(stąd i nazwa).

Czyli nie są od testowania resetu kontrolek czy czyszczenia propertek, bo to jest raczej trywialne. No, chyba, że masz tam faktycznie logikę, która tym steruje(nie patrzyłem w kod, opieram się na wątku). Z tym, że wspomniany case też został wyjaśniony :)

Dlatego też nie da się jednostkowa przetestować metody, która wyciąga dane, mapuje, przerabia i woła trzydzieści innych metod - tych jednostek tam jest... No, dość dużo ;)

0

A co ta aplikacja w ogóle robi.? Próbowałem coś zrozumieć z TODO'sa, ale tam jakieś więzienne grypsy są:

jak przybral to zle czy kon zmienil ostatnio trenera - jak tak to dobrze, bedzie chcial sie wykazac jak klacz wystawiana vs ogierom, to pozytywnie nie da sie - shipping - czy kon przyjezdza?

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