Unit test what should be tested

Unit Testing is done during the development coding phase of an application by the developers. Unit Tests isolate a section of code and verify its correctness. A unit may be an individual function, method, procedure, module, or object. Unit testing is a WhiteBox testing technique that is usually performed by the developer. Though, in a practical world due to time crunch or reluctance of developers to tests, QA engineers also do unit testing.

Unit Testing is important because software developers sometimes try saving time doing minimal unit testing and this is myth because inappropriate unit testing leads to high cost Defect fixing during System Testing , Integration Testing and even Beta Testing after application is built.

If proper unit testing is done in early development, then it saves time and money in the end. In order to do Unit Testing , developers write a section of code to test a specific function in software application.

Developers can also isolate this function to test more rigorously which reveals unnecessary dependencies between function being tested and other units so the dependencies can be eliminated. Developers generally use UnitTest framework to develop automated test cases for unit testing. Unit testing is commonly automated but may still be performed manually.

Software Engineering does not favor one over the other but automation is preferred. Engineers make assumptions all the time when coding. When these assumptions match the real code, everything is fine.

As it turns out, unit tests are a great tool to document such assumptions. If the assumption turns out to be false—or becomes false after a while—the test fails. So, we can say that unit tests, besides helping ensure the overall quality of the application, doubles as a tool for developers to document their assumptions and have trust in the code they write.

The line between unit tests and integration tests can be hard to see for beginners. Both unit tests and integration tests can be written using the same tools. They might even look very alike, or even identical. Also, integration tests often test several modules of the application in an integrated manner—hence the manner.

So, integration tests offer a more high-level view of the application than unit tests do. Because of that, the feedback they provide is both more realistic and less focused.

Due to their reliance on external dependencies, they can be significantly slower and have a more difficult setup. So, how to ensure code is testable? A complete answer to this question would be worth a post of its own. A short answer is simply: avoid the enemies of testability.

To fight side effects and nondeterminism, adopt pure functions. Against too many dependencies, use dependency injection. Prefer smaller and more focused modules over gigantic ones that do too much. Keep cyclomatic complexity at bay. For instance, the Mocha testing framework, by default, considers any test that takes more than 75ms to run as a slow test.

After all, test code is no different than production code, except when it comes to their purposes. It can have bugs as well. There are several techniques we can apply to have a high degree of confidence in the correctitude of our tests. One of those is to keep your tests with low cyclomatic complexity. Cyclomatic complexity is a code metric that indicates the number of possible execution paths a given method can follow.

A piece of code with lower complexity is easier to understand and maintain, which means developers are less likely to introduce bugs when working on it. So, how do you keep your tests simple? Simple: measure the cyclomatic complexity of your tests using, for instance, a linter tool and do your best to keep it low.

This item is sort of a continuation of the previous one. Tests that fail to follow this best practice are highly likely to disrespect the previous one as well. The code represents a solution for the famous StringCalculator kata, proposed by Roy Osherove. The challenge consists of writing a function that takes a string containing a list of comma-separated numbers and returns their sum.

There are further rules ignore numbers greater than , throw if negative numbers are passed, etc. As you can see, the test cases are really repetitive. Here is the new version of the tests:. Someone might think that the new tests are better than the old versions.

Well, not in this case. The code above is problematic because the test code is now almost a carbon copy of the implementation code. But since the tests mirror the implementation, they might still pass, which puts you in a terrible situation: the implementation is wrong, but the tests might fool you into thinking otherwise.

It provides the project team with a quick view of the risks and the priority with which each of these risks needs to be addressed. Probability is the measure of the chance for an uncertain event to occur — exposure concerning time, proximity, and repetition. It is expressed as a percentage. Severity is the degree of impact of damage or loss caused due to the uncertain event. The priority is classified into four categories, which are mapped against the severity and probability of the risk, as shown in below image.

How Much Unit Testing is Enough? JUnit FAQ. Unit Testing - What not to test- StackOverflow. Risk Based Testing : When and How? Art of Unit Testing Testing 2nd book. How We Test Software at Microsoft book. Experiences of Test Automation book. See the original article here. Performance Zone. Thanks for visiting DZone today,. Edit Profile. Sign Out View Profile. Over 2 million developers have joined DZone. Unit testing can often take on a rather broad connotation.

We try to help narrow down the phrase in terms of what it should and shouldn't cover. Like 5. Join the DZone community and get the full member experience. Join For Free. Benefits of Unit Testing Unit tests prove that your code actually works You get a low-level regression-test suite You can improve the design without breaking it It's more fun to code with them than without They demonstrate concrete progress Unit tests are a form of sample code It forces you to plan before you code It reduces the cost of bugs It's even better than code inspections Unit tests make better designs Test Strategy In most cases, it will be a heuristic approach.

Run the test again. Repeat : You remember the edge case that the test didn't cover, right? So, now it's its big moment.

Write a testcase that covers that situation, watch it fail, write some code, see it pass, refactor. You are working on some specific piece of code, and this is exactly what you want to test. This means that you should not be testing library functions, the standard library or your compiler. Also, try to avoid testing the "world". This includes: calling external web APIs, some database intensive stuff, etc.

Whenever you can try to mock it up make an object that follows the same interface, but returns static, predefined data. For unit tests, start with testing that it does what it is designed to do. That should be the very first case you write. If part of the design is "it should throw an exception if you pass in junk", test that too since that is part of the design. Start with that. As you get experience with doing that most basic of testing you'll begin to learn whether or not that is sufficient, and start to see other aspects of your code that need testing.

The stock answer is to "test everything that could possibly break". What's too simple to break? Data fields, brain-dead property accessors, and similar boilerplate overhead. Anything else probably implements some identifiable portion of a requirement, and may benefit from being tested.

Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. What should you test with unit tests? Ask Question. Asked 11 years, 2 months ago. Active 4 years, 11 months ago. Viewed 52k times. Improve this question. Take a look at Roy Osherove's Blog. There is plenty of information on unit testing there including videos. He has also written a book, "The art of Unit Testing" which is very good.

I wonder what do you think about it after almost 5 years? Because more and more I feel that people should better know "what to not unit-test" nowadays. Behaviour driven development has evolved from the questions like you have asked.

Add a comment. Active Oldest Votes. My personal philosophy has thusfar been: Test the common case of everything you can. This will tell you when that code breaks after you make some change which is, in my opinion, the single greatest benefit of automated unit testing.

Test the edge cases of a few unusually complex code that you think will probably have errors. Whenever you find a bug, write a test case to cover it before fixing it Add edge-case tests to less critical code whenever someone has time to kill.