3

Say I want to assert that a certain option menu is displayed in the front-end of a project. The menu is on screen X and I have to first select data in Y to get to X. Now, it doesn't matter at all what data I select in Y, it will always lead to X.

But sometimes, depending on the data, I will get a screen Z which I can just skip through. Now obviously, if I write the test in a deterministic manner the test may fail if the data I selected leads to screen Z.

The data I'm talking about is test data, set up before every test to the same state. So theoretically, I could just select one data entry that I know will not go to screen Z.

But, I could also simply include a check to see if I'm on screen Z after selecting the data and skip Z. Now, even changes to the test data (though rare, it happens) would not break my test.

Somehow I don't like this approach but I can't really explain why. Adding a method to check for Z would add a (probably) "useless" method to my test framework.

So my question is, are branches to handle conditional behaviour that is not being tested in that specific test okay? Are there any problems with this approach? Is it good to do this?

Improve this question
5
  • 7
    strictly speaking this sounds like an integration or system test not a unit test Commented Oct 2, 2013 at 8:47
  • That may be correct, I don't really know what this kind of test is called. I assumed unit test, because it doesn't matter where the project is deployed, the front-end is a functionality that should always be there... Commented Oct 2, 2013 at 8:58
  • After reading up the definition, I don't think this is a integration/system test. I'm explicitly testing the "frontend" unit, it just happens on a deployed platform... I think. Commented Oct 2, 2013 at 9:00
  • well you know the code so you are best placed to say, but from the description it sounds like you are testing more than one thing, which either means you are testing more than one unit or you are breaking the SRP Commented Oct 2, 2013 at 10:00
  • 1
    I would call this a UI/interface test. Depending on exactly what you are testing, can be an automated acceptance or functional test. Commented Oct 2, 2013 at 14:48

3 Answers 3

Reset to default
8

It's not unreasonable for a change in test data to change the outcome of a test.

I wouldn't put the conditional branch in, I would ensure that I have a separate test with a set of test data that always goes to screen Z so that behaviour can be tested.

If the initial test you're trying to do is that when data from Y is entered, screen X is displayed then that's exactly what you should test - don't overcomplicate tests.

Y -> Z -> X is not the same as Y -> X and I presume some business logic (which should be tested) controls the appearance of Z?

Improve this answer
2
  • Y -> Z -> X is in this case the same as Y -> X (Z just sets something that could have been set in Y). And yes, Z is of course tested in a seperate test. Commented Oct 2, 2013 at 8:57
  • 5
    Not to be pedantic but just because something is a no-operation, this does not make it "the same". Commented Oct 2, 2013 at 9:29
7

I would avoid branches in the testing code- I would be wanting to find the exact conditions that took me along the X->Y path and test the commonest and boundary paths for that. Then I would identify the conditions that took the user along the X -> Z -> Y path and write a separate test for the boundary conditions of that.

If you aren't using completely deterministic data/mocks so that your tests don't behave totally predictably, you aren't writing unit tests.

If the two tests have a lot in common, you might want to put the shared code into helper or setup/takedown methods so you aren't repeating yourself too much inside your tests.

Depending on the platform you are working with it can be very helpful to have parameterised tests so you can run different data through the same test to cover different boundary conditions.

Improve this answer
2

In general when you are testing, you want to avoid any uncertainty and you want to keep the test to the point. Uncertainty/randomness in the data or in the test logic will only make things more complicated/less understandable to you or other developers which leads to a maintenance nightmare. This is true for all tests across the board.

This means only set up data (if possible) that is required to test that one thing. This will make the tests easier to understand and maintain because there is less distractions from what matters. It also makes tests more decoupled from each other because the data you are using for the one functionality does not interfere with other tests. For smaller applications with a small test suite you might get away with 'single large test data' up front. However, maintaining such large data set becomes a nightmare when you are working with a larger application.

As far as the test logic is concerned, you do not want to clutter it with conditionals like if by any chance I got this intermediate thing, ignore it and continue. In a test you should always know what action leads to what state so you should specifically code for it. Such conditional statements only distract from what is important about the test and may lead to more code that simply deals with these 'possibilities' than the test code itself. Another problem with this approach is that the application and test code can get out of sync. As the application evolves you remove state Z but it does not get cleaned up from the test code itself because it was there only conditionally (tests will not break, therefore not signal that there is a problem). This can be extremely stressful especially for someone who is new to the code base because now they have to dig to see what this code is all about.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.