Testing Terminology

From Logic Wiki
Jump to: navigation, search


Positive Scenario

Scenario that tests what an app promise to do.

Negative Scenario

Scenario to break the application.

Unit Testing

This type of testing is meant to focus on one unit of code, usually a class or a method and assure the developer that the proper expected behavior is returned.

Integration Testing

Integration Testing is when a program accesses an external resource to confirm that the code is functioning properly (i.e. database calls or loading a file). If you are making database calls in your unit tests, then they aren't called unit tests...they are integration tests.

Regression Testing

Over time, as your system grows, you accumulate more and more unit tests. Those old unit tests need to run just like the new ones. Regression testing is finding defects after a major code change has occurred. Those old unit tests may need refactored to match the new code. Of course, if it is new code, I could almost guarantee that at least 25-50% of your unit test code would fail (considering it's a major change to your code base).

Load Testing

After your website is built, you may need to perform some load testing to determine the stamina of your code. What I mean is that load testing is primarily concerned with how well the system runs under a specific load of users or large amounts of data.

What are some general guidelines for Unit Testing?

Based on my experiences, here are some of my guidelines I've learned over the years.

Make sure you unit tests tests what needs to be unit tested...and nothing more.

If you have a simple POCO (Plain Old CLR Object) with a list of properties with no implementation or business rules behind it, I'm guessing you don't need to test it.

Your code should be unit testable. If it's not, you may need to rethink your design.

Sometimes, it's a good idea to write your unit test first. That way, you get a clear understanding and perspective of how developers will interact with your code. If it's not clear in your unit test, what makes you think that developers will understand it in production? ;-)

You really don't need to mock everything.

Some users mock the heck out of everything because they can. For example, your business objects. No mocking is necessary. You can new one up just to see if code is structurally sound and passes a specific business requirement.

If a business routine or rule is really complex, write unit tests around it (or take a hammer to it).

Confirm the nature of the routine by writing unit tests. If it's really complicated and it's a long method, "break" it into manageable pieces of code. Breaking this code smell into manageable chunks of code will accomplish two things: smaller, testable routines for unit testing and a better understanding of the code since it's refactored.

Write small unit tests to achieve quick wins

I've seen a number of developers write elaborate unit tests showing 50 lines of code to return back one number. Remember when I said your unit tests will show developers how complex your system is? While 50 or more lines of code in a unit test is definitely a design problem/code smell, the best unit tests focus on smaller parts of the system and achieve better granularity across the system components.

Use as many Asserts to confirm the behavior works as expected

I've heard a number of developers argue that you need only one Assert per unit test. I disagree. You may return a number of parameters in a ViewModel that HAS to have a list of records, a total, and a page title. I would not make three methods to check each one separately. I would create one unit test with three Asserts.


https://www.danylkoweb.com/Blog/the-ultimate-guide-to-unit-testing-in-aspnet-mvc-E2