Tag Info

New answers tagged

1

For any given piece of code, there should be at most one place that is responsible for exhaustively testing that code. There can be any number that incidentally test it; you just don't want to waste effort running up an exponentially large mountain. For your example, the minimum set of test cases is a list of invalid forumulas, plus a list of valid ...


0

Since I do not have enough reputation to upvote Frank's answer, I will have to add my own! To answer directly, unit testing is critical, even for non-critical web applications. Have you considered what vulnerabilities exist in your search engine? There may be issues in your web app that some customers have noticed and not provided notification. Unit ...


6

No, a unit test should test the thing it's targetting and nothing else. You're allowed to assume that any other method that this method calls does the right thing, because they must have their own unit tests. If one of those helper methods were wrong, you'd get an alert when that other test is run, and since you're supposed to run the entire test suite and ...


3

To be honest, these days I am more and more inclined to simply comment on this as unprofessional behavior. There are very good books like Legacy Code [1], Refactoring [2], or Clean Code [3], which explain much better why professional software development should always include tests. Warning: the following are my opinions and sometimes phrased rather ...


0

This depends on how good you are at writing tests, as well as, how much you want to maintain and improve your test writing skills. If you're not good at it and don't care to learn, it could increase the amount of time wasted. Of course you may think having to write tests will slow down your rapid release cycle, but at some point the application may become ...


0

Automated testing should be all about testing smallest pieces of functionality in as big isolation as possible. This allows you to define tests clearly, define most of the edge cases and have tests run in short time. Trying to test through multiple layers of code results in unclear tests, hard to test edge cases and tests that might take days to run. So I ...


0

I think it's right that each class has its test class. The idea is to centralize all unit tests related to the target class in a single test class. Then, for example, MyClass.java will have its test class, MyClassTest.java.


1

Is it better to have a separate class for each method, or have just one test class for every actual class? If you have the need to write separate test classes for methods of one class, then you have the wrong design. Methods should be small, easy to read, easy to test and easy to change. The tests could be a bit longer, than the original code due to ...


2

To your specific question, the junit convention is to have a 1-1 correspondence between your application classes (Foo1.java, Foo2.java) and junit test classes (Foo1Test.java, Foo2Test.java) -- http://junit.sourceforge.net/doc/faq/faq.htm#tests_13 That said, I agree wholeheartedly with Kilian's highlighting of the importance of the spirit/goals of unit ...


2

How your tests are organized is rather unimportant compared to the importance of having them at all. The most important thing for a good test suite is that it covers all of the functionality; that ensures that whenever a regression defect is introduced, you'll notice right away. Whether to write one test for each method, one test for each input value ...


3

Of course you must test the values of an object returned by the tested method - at least those that are necessary to fulfill that method's contract. What else are you supposed to test? Its class? That's already guaranteed by the type system. (And if your type system doesn't enforce strict types, all the more reason to test that a property of the returned ...


1

I would agree to test a lot. In TDD you normaly write a Test first and THEN Implement. So if you don't write a Test which checks if a Person has an Age, then you don't implement it. TDD workflow: Write a Test which is not running (Red). Implement only that this Test and the others are running (Green). Refactor. Although I must say that I don't Test ...


1

One huge advantage is that in many cases you can use your selenium tests against the production codebase and deployment. They are certainly brittle and non-comprehensive tests in many ways. On the other hand they can actually hit all of the moving parts moving together which is a space traditional unit tests just can't hit. You can even extend this out to ...


3

UI testing is hard. For the most part, it doesn't lend itself well to unit testing. Tools like Selenium are designed to fill this gap. For the most part, they do this by automating the user interface, simulating the operations that a user might perform via mouse clicks and typing. But these tests tend to be brittle, and they are generally not ...


5

Unit testing is just one of the multiple types of testing. Basically, you'll find three types of tests: Unit tests. Each of those tests ensure that a tiny piece of application is working as expected. For example, a unit test will ensure that if, on an e-commerce website, I create an instance of a Product class with a price inferior to zero, an exception ...


1

The second is better, but int internal_foo(bool *arg); // modifies argument keeps it testable while fixing your tiny function tradeoff, and bool internal_foo(bool arg); // returns new value is even better if you don't use the existing return value. Note that in general though, having lots of little functions isn't necessarily a problem. If it makes ...


1

You may want to consider only running tests that have recently failed. Given that the entire set takes 6-7 hours (i.e. is runnable nightly), you could base your tests set on the past few nights' results. If you mix in a few randomly selected tests for broader coverage over the course of the day, you should get a good chance of catching errors. This idea ...


1

TL;DR: Create a Dependency DAG from affected modules Identifying the tests that are impacted by a particular change is the same as identifying when to recompile/relink a object file. Create a dependency directed acyclic graph (DAG) starting at the modified module. You should be able to traverse all imports to identify the what needs to be tested. You can ...


2

I disagree with Infer-On's answer. Indeed, though not always achievable in practice, one should strive for having a single error cause just one test to fail. The main fallacy of your assumptions is in your list of behaviors. There is one crucial test missing from your list based on the information you provided: 0. Check to see if the method returns null ...


13

Your assumption is wrong, I feel like a single error should only result in one unit test failure every unit-test test only one aspect of the method so: Check to see if the method returns an empty collection if no locations are found. Check to see if the method returns the correct number of locations. Check to see if the data in the locations the ...


6

Unit tests don't test gameplay. There's no programmatic criteria to see if a game is fun, or a level is the right difficulty. Unit tests will test that your roguelike mapgen actually produces a level with a stairs up and a stairs down. It will test that your encumberance rules are setup that your character actually moves slower when weighted. It will make ...


2

Configuration files in source control are pretty much equivalent to constants in a programming language. And the distinctive thing about constants, at least in most programming languages, is that if you treat them as the unit under test, they literally cannot have any internal bugs. For example: final static double PI = 4.2; has no locally detectable ...


0

No overkill. Configuration file values are intended to be edited by administrators, but ... Configuration files that live in source control probably are part of a deployed default configuration. As such, they should only be changed with changing the default configuration in mind, however ... Developers need to be able to edit them as well, to help isolate ...


3

A configuration file is part of the configuration of the application. As such, you can test it in a couple of ways. One way is to reference your version control system and see if the file is identical to what should have been deployed. You can short cut this process by creating a separate file with a hash (what is called a digest) of the configuration file ...


7

There are certain static analysis tools that can help determine "test impact", which can then run the effected tests. But I can't help but feel that you're solving the symptom, not the problem. When I worked in QA, there was one overriding mantra that has helped me as a developer: "don't trust the developer". Even if I could determine "relevant", I wouldn't ...


1

If your unit tests are taking 6-7 hours to run, something is wrong. They should take a few minutes at most. Note that I say should - I know how difficult this can be in reality. Maybe it's time you start mocking out your objects so that you're not dependent on the filesystem or DB or whatever is slowing you down. You don't want to have to deal with working ...


7

There's a fair amount of debate in terms of when, where, and how to test an application of X complexity. And a fair amount of political zeal on all sides. In my own experience, I've been on a lot of projects that were small and simple, arguably requiring little automated testing. And truthfully, I developed with nearly zero automated testing and horrendously ...


2

First of all this should be tested by system/acceptance tests that cover what ever feature needs this class for unit tests I'd say the answer is mostly no, there is nothing useful to test here, the only time I would unit test is if it was more effort to justify why I'm not testing this class than to test it (sometimes the case with safety related stuff)


0

This is not horribly straightforward but not impossible. The biggest hurdle is picking a tool and method to automatically stand up the database in the state you want that will work silently from the command line. Personally I prefer roundhouse for this task but there are certainly other options. Insofar as getting it integrated with visual studio, the most ...


3

It appears to me that you have a fundamental problem with your components. C should do what C needs to do, and be tested, documented and designed to do just that. When you have a situation where C is designed to "do what B wants" you have an abusive relationship, one that becomes very clear when A arrives and wants C to do something slightly different. ...


2

I would argue that you have missed the addition of some of the necessary features because they weren't being highlighted as for unit testing. For example, unit testing in C# is mainly driven by using attributes. The Custom Attributes feature provides a rich extension mechanism that allows frameworks like NUnit to iterate and compete, with things like ...


6

A lot of languages have support for testing. C's asserts are tests that the program can fail. That's where most languages stop, but Eiffel and more recently Ada 2012 have preinvariants (things the arguments to a function must pass) and postinvariants (things the output of a function must pass), with Ada offering the ability to reference the initial arguments ...


2

Some proponents of strongly typed functional languages would argue that these language features reduce or eliminate the need for unit tests. Two, imho, good example of this for this is from F# for Fun and Profit here and here Personally, I am still believe in the value of unit tests, but there are some valid points. E.g. if an illegal state is ...


13

Because testing, and particularly test-driven development, is a deeply counter-intuitive phenomenon. Almost every programmer begins their career believing they are much better at managing complexity than they actually are. The fact that even the greatest programmer cannot write large and complex programs without severe errors unless they use lots of ...


16

There's lots of reasons. Eric Lippert has stated many times that the reason feature X isn't in C# is because it's just not in their budget. Language designers don't have an infinite amount of time nor money to implement things, and each new feature has maintenance costs associated with it. Keeping the language as small as possible isn't just easier for the ...


32

As with many things, unit testing is best supported at the library level, not the language level. In particular, C# has numerous Unit Testing libraries available, as well as things that are native to the .NET Framework like Microsoft.VisualStudio.TestTools.UnitTesting. Each Unit Testing library has a somewhat different testing philosophy and syntax. All ...



Top 50 recent answers are included