1

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?

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.

  • So if this is defined as unit test, what would an integration test look like then? Are you saying I shouldn't bother writing tests? The reason I want to add them is because new code is being added constantly and manually testing everything to make sure something didn't break is a drag on my (and everyone else's) time. – St0mX Feb 13 at 23:15
  • @St0mX better now? – candied_orange Feb 14 at 0:12
  • They don't qualify as unit tests because in those methods I make an HTTP request which then interacts with the database by fetching and/or adding things to it. Thank you for the clarification. – St0mX Feb 14 at 0:47
  • But I still do not understand how I should proceed from here on out. You are advising against writing tests in a codebase that doesn't have any but I don't want to manually test everything I build it's too time consuming. What are the reasons in my case for NOT starting to write tests? – St0mX Feb 14 at 0:49
  • 1
    I'm not advising against writing tests. I'm saying doing it now is going to be hard. Just not as hard as trying to live without any unit tests. Read the book. It's to late to do this the easy way. That doesn't mean it's to late to test. It's never to late to test. Manual testing should never ever be preferred over an automated test. Manual testing should be used to develop automated tests. – candied_orange Feb 14 at 0:59
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.