Integration Testing: Should a test check every validation?

Question

I am somewhat new to writing tests and I want to build that habit into my workflow. So for example I might write a test that a user can create a blog post however I'm not sure on how to do that effectively.

Should I have a test case to verify that every field is validated?

By that I mean I could either only write one test case like :

• testThatUsersCanCreateBlog

or...

• testThatUserCanCreateBlog

• testThatUserCannotCreateBlogWithoutTitle

• testThatUserCannotCreateBlogWithoutTags

• testThatUserCannotCreateBlogWithoutImage

• etc....

Now the first approach seems kind of useless because I'm just going through the "happy path" so I'm not really testing anything but the second approach feels a bit invasive because I feel like my test becomes a burden instead of an asset.

I've heard that in theory a test well written should not need to be changed every time the tested item is changed but in the 2nd instance if I add or remove fields to the Blog model then I am required to make the same adjustments in my test to keep it consistent so it doesn't throw up an error.

With extensive forms of 20+ fields on ~50 pages this picture looks wrong somehow. Am I missing something?

Answer 1

These aren't integration tests. These are unit tests. They should be written before the operational code that makes them pass. Writing them shouldn't be a redundant after thought. It should be an expression of your design.

Done right they will ensure that however your operational code is implemented it enforces these rules. That frees you to refactor your implementation confident that your changes haven't broken the rule enforcement.

Test Driven Development is meant to start before you develop operational code. Tests aren't easy to retrofit into existing operational code that wasn't designed with it in mind. Such code is called legacy code. If you have to work with it I recommend reading "Working Effectively with Legacy Code" by Michael Feathers. He teaches you how to find seams in old code that you can exploit to add tests. But this is a poor substitute for writing testable code from the start.

Feathers also gives the best definition of a unit test:

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

None of the tests you mention have to violate these rules so they should be unit tests not integration tests.

Unit tests should be fast. So fast you can run them while you type code.

Answer 2

The short answer is go with your second example but it is not a list of all test cases but a tree structure of test cases from broad to specific. Chose a model to support/bound your approach, get it approve and stick to it until told otherwise.

You will go from broad to more specific to units testing and won't miss anything. Your test cases must be writen to show that the requirement have been meet no more no less. Your test results will roll up as supporting evidences for the next test level.

You can stop here if you want, the rest of my post is for educational purposes only.

In my shop, we use the V model of S/W engineering using eSAFE approach (commonly known as fast prototyping). All test are written in parallel with the requirements, from business requirement all the way down to S/W derived requirement.

This is probably outside of your span of controls but look up "V model", draw an horizontal line across the "V" and bring it down to where you sit in that process. Write you requirements and tests from that point, down the V as far as needed for what you are responsible for.

Brief tutorial here https://www.tutorialspoint.com/sdlc/sdlc_v_model.htm and this approach scale down as far as needed to meet your needs.