Geek Answers Handbook

TDD, What are your methods for finding good tests?

I am writing a simple web application using Linq to Sql as my datalayer, since I really like Linq2Sql. I read a bit about DDD and TDD lately and wanted to give him a chance.

First of all, it seems to me that Linq2Sql and DDD are not going too well. Another problem is finding tests, it’s actually very difficult for me to identify good tests, so I wanted to ask, “What are your best methods for finding good test cases.”

+4
source share
6 answers

The discovery of a test case is more an art than a science. However, simple recommendations include:

  • Code that you know is fragile / weak / may break
  • Follow the user's script (what your user will do) and see how it touches your code (often it means debugging, different profiling time and other time, it just means thinking about the script) - whatever points the user touches on your code, this is the most high priority for writing tests.
  • During your own development, the tests you ran led to errors detected - write tests to avoid repeating the code with the same behavior.

There are several books on how to write test cases, but if you don’t work in a large organization that requires documented test cases, it’s best to think about all the parts of your code that you don’t like (which are not “clean”) and make sure that you can fully test these modules.

+5
source

Well, the standard interpretation of TDD is that tests drive your development. So basically you start with the test. This will fail, and you will write code until this test passes. Thus, it depends on your requirements, however you are going to collect them. You decide what your application / function needs to do, write a test, and then code, until it passes. Of course, there are many other methods, but this is just a brief expression of what the TDD world usually thinks.

+5
source

Think about it . Read the code. Ask yourself a question: for example. can this pointer never be NULL here? What happens if this method is called before initialization?

Do not make assumptions such as "this file will always be there." Test.

Think of cross cases, boundaries, negative values, overflows ...

An error is often grouped by a cluster. Look around when you find him. Also look for the same error elsewhere.

+1
source

Tune your mind to the actual goal of testing: finding bugs.

Be creative in imagining what can make your program fail.

Your tests should find errors, and not confirm that your program is in order.

+1
source

I regularly write tests for third-party APIs. That way, when the API updates, I know if I will break or not.

0
source

I think this is a useful method:

Using contracts and boolean queries to improve the quality of automated test generation

Reference: Lisa (Ling) Liu, Bertrand Meyer and Bernd Schöller, using contracts and logical queries to improve the quality of automatic test generation, in TAP: Tests and Evidence, ETH Zurich, February 5-6, 2007, ed. Yuri Gurevich and Bertrand Meyer, Lecture Notes in Computer Science, Springer-Verlag, 2007.

0
source

More articles:


All Articles