New answers tagged

2

Say it's broken. Say you're thinking about something else entirely and don't have a lot of patience for this bug. Which test do you wish had been written now? I test as much as I can get away with. At some point you have to stop and get paid. Keeping that in mind, it's not simply behavor. It's the boundaries. Your behavor is 'show me the neighbors'. ...


5

You can do two things: First, use parameterized tests to minimize the duplication of the test code: cases([ [0, [1, 8, 9]], [1, [0, 2, 8, 9, 10]], // more testcases here ]) .it('sample', function(n, expected) { expect(getNeighbors(n)).toEqual(expected); }); Second, partition your testcases into equivalence classes where ...


0

I think in this case the numbers should be termed Arbitrary Numbers, rather than Magic Numbers, and just comment the line as "arbitrary test case". Sure, some Magic Numbers can be arbitrary too, as for unique "handle" values (which should be replaced with named constants, of course), but can also be precalculated constants like "airspeed of an unladen ...


3

The key here is your perspective on a particular function as trivial. Most of programming is trivial: assign a value, do some math, make a decision: if this then that, continue a loop until... In isolation, all trivial. You just got through the first 5 chapters of any book teaching a programming language. The fact that writing a test is so easy should be a ...


1

Should savePeople() be unit tested, or would such tests amount to testing the built-in forEach language construct? This has already been answered by @BryanOakley, but I have some extra arguments (I guess): First a unit test is for testing the fulfillment of a contract, not the implementation of an API; the test should set preconditions then call, then ...


5

Should bakeCookies() be tested? Yes. How should a function like this be unit tested, assuming you think it should? It's hard for me to imagine any kind of unit test that doesn't simply mock dough, pan, and oven, and then assert that methods are called on them. Not really. Look closely at WHAT the function is supposed to do - it is supposed to set the ...


11

Should savePeople() be unit tested Yes, it should. But try to write your test conditions in a way that is independent from the implementation. For example, turning your usage example into a unit test: function testSavePeople() { myDataStore = new Store('some connection string', 'password'); myPeople = ['Joe', 'Maggie', 'John']; savePeople(...


1

You should also test bakeCookies - what would/should e..g bakeCookies(egg, pan, oven) yield? Fried egg or an exception? On their own, neither pan nor oven will care about the actual ingredients, since none of them are supposed to, but bakeCookies should usually yield cookies. More generally it can depend on how dough is obtained and whether there is any ...


1

I think your question boils down to: How do I unit test a void function without it being an integration test? If we change your cookie baking function to return cookies for example it becomes immediately obvious what the test should be. If we have to call pan.GetCookies after calling the function though we can question whether its 'really an integration ...


12

The primary value such a test provides is that it makes your implementation refactorable. I used to do a lot of performance optimizations in my career and often found problems with the exact pattern you demonstrated: to save N entities into the database, perform N inserts. It's usually more efficient to do a bulk insert using a single statement. On the ...


92

Should savePeople() be unit tested? Yes. You aren't testing that dataStore.savePerson works, or that the db connection works, or even that the foreach works. You are testing that savePeople fulfills the promise it makes through its contract. Imagine this scenario: someone does a big refactor of the code base, and accidentally removes the forEach part of the ...


29

Usually this kind of question comes up when people do "test-after" development. Approach this problem from the point of view of TDD, where tests come before the implementation, and ask yourself this question again as an exercise. At least in my application of TDD, which is usually outside-in, I'd not be implementing a function like savePeople after having ...


2

Should savePeople() be unit tested, or would such tests amount to testing the built-in forEach language construct? Yes. But you could do it in a way that would just retest the construct. The thing to note here is how does this function behave when a savePerson fails half way through? How is it supposed to work? That is the sort of subtle behavior that ...


0

I won't venture as far as to say a definitive yes/no, but here are some questions you should ask yourself when deciding whether it's OK or not. If the numbers don't mean anything, why are they there in the first place? Can they be replaced by something else? Can you do verification based on method calls and flow instead of value assertions? Consider ...


8

This depends heavily on the function you are testing. I know lots of cases where the individual numbers do not have a special meaning on their own, but the test case as a whole is constructed thoughtfully and so has a specific meaning. That is what one should document in some way. For example, if foo really is a method testForTriangle which decides if the ...


3

If you want to test a pure function on one set of inputs that aren't boundary conditions, then you almost certainly want to test it on a whole bunch of sets of inputs that aren't (and are) boundary conditions. And to me that means there should be a table of values to call the function with, and a loop: struct test_foo_values { int bar; int baz; ...


6

Why do we want to use named Constants instead of numbers? DRY - If I need the value at 3 places, I only want to define it once, so I can change it at one place, if it changes. Give meaning to numbers. If you write several unit tests, each with an assortment of 3 Numbers (startBalance, interest, years ) - I would just pack the values into the unit-test as ...


0

Tests are different from production code and, at least in units tests written in Spock, which are short and to the point, I have no issue using magic constants. If a test is 5 lines long, and follows the basic given/when/then scheme, extracting such values into constants would only make code longer and harder to read. If the logic is "When I add a user ...


1

Firstly let’s agree that “unit test” is often used to cover all automated tests a programmer writes, and that it is pointless to debate what each test should be called…. I have worked on a system where the software took a lot of inputs and worked out a “solution” that had to fulfil some constraints, while optimizing other numbers. There were no right ...


3

...but in this case the numbers actually have no meaning at all The numbers are being used to call a method so surely the above premise is incorrect. You may not care what the numbers are but that is beside the point. Yes, you could infer what the numbers are used for by some IDE wizardry but it would be far better if you just gave the values names - even ...


19

If you're using arbitrary numbers just to see what they do, then what you're really looking for is probably randomly generated test data, or property-based testing. For example, Hypothesis is a cool Python library for this sort of testing, and is based on QuickCheck. Think of a normal unit test as being something like the following: Set up some ...


9

Your unit test name should provide most of the context. Not from the values of the constants. The name/documentation for a test should be giving the appropriate context and explanation of whatever magic numbers are present within the test. If that is not sufficient, a slight bit of documentation should be able to provide it (whether through the variable ...


75

When do you really have numbers which have no meaning at all? Usually, when the numbers have any meaning, you should assign them to local variables of the test method to make the code more readable and self-explaining. The names of the variables should at least reflect what the variable means, not necessarily its value. Example: const int startBalance = ...


5

Is this the correct way of testing the script? assert_equal(calculate("Degree", "Sin", 90), Math.sin(90 * Math.PI/180)) This tests if your function behaves identical to the standard library. Not if it behaves the way you expect it to behave. It is better to hardcode the expected result: assert_equal(calculate("Degree", "Sin", 90), 1.0) how am ...


1

While not being a python developer, the tests shall be readable. Thus I'd suggest rewriting your test: from src.trigonometry import calculate def test_calculate(): expected = 0 actual = calculate("Degree", "Sin", 90) assert_equal(expected, actual)


1

I can relate to your expierience - our code base had almost no tests and was mostly untestable. It took literally ages to develop something and fixing productions bugs took precious time from new features. For a partial rewrite, I vowed to write tests for all core functionality. At the beginning, it took considerably longer and my productivity suffered ...


2

Question is, how much of a time difference would writing unit-tested code over untested code, and how does that time difference scale as project scope widens? The problem gets worse as the age of the project increases: because whenever you add new functionality and/or whenever you refactor existing implementation, you ought to retest what's previously be ...


2

There have been a long history of Programmers board promoting TDD and other test methodologies, I won't recall their arguments and agree with them, but here is additional things to consider that should nuance a bit: Testing isn't equally convenient and efficient depending of context. I develop web software, tell me if you have a program to test the whole ...


0

Change the scope of the field. If the name matters and that behavior should be tested, then make that field public. In this case, make it public read only. Then one will be able to test the state of the object after the constructor is fired.


14

Despite there being a lot of answers already, they are somewhat repetitive and I would like to take a different tack. Unit tests are valuable, if and only if, they increase business value. Testing for testing's sake (trivial or tautological tests), or to hit some arbitrary metric (like code coverage), is cargo-cult programming. Tests are costly, not only in ...


0

Trusting the dependent class that it works properly, hoping there would fail some unit tests when something there does not work, then it should this be tested very vell. Maybe there are missing some important unit tests? There can be an untested case that would create an error, that will be produced in my originary testing class, and would not be catched in ...


6

If it is the case that the name of the car isn't publicly available in any way at all, then it makes no sense to test it, because obviously it doesn't matter to any client code. If the name of the car matters, even if you can't actually see it by inspecting the field, then exercise some method that relies on the name being correct and assert against some ...


0

I've managed to clean up my stateless classes by using default arguments. For example, virtual unsigned long foo( const ISomeInterface & dependency = ProductionDependency()) const override final; I appear to have met all the criteria in my original question... unit test stateless classes (without the dependencies) I can unit test by ...


2

Programmers, like people dealing with most tasks, underestimate how long it actually takes to complete it. With that in mind, spending 10 minutes to write a test can be looked at as time one could have spent writing tons of code when in reality, you would have spent that time coming up with the same function name and parameters you did during the test. This ...


1

Some aspects to consider, not mentioned in the other answers. Extra Benefit/Extra Cost depend on experience with writing unittests with my first unit-test project the extra costs trippled because i had to learn a lot and i made a lot of mistakes. after 10 years of experience with tdd i need 25% more coding time to write the tests in advance. with more ...


1

An oft overlooked benefit of TDD is that the tests act as a safeguard to make sure you aren't introducing new bugs when you make a change. The TDD approach is undoubtedly more time consuming initially but the takeaway point is you'll write less code which means less things to go wrong. All those bells and whistles you often include as a matter of course ...


100

I agree with the rest of the answers but to answer the what is the time difference question directly. Roy Osherove in his book The Art of Unit Testing, Second Edition page 200 did a case study of implementing similarly sized projects with similar teams (skill wise) for two different clients where one team did testing while the other one did not. His ...


28

There is only one study I know of which studied this in a "real-world setting": Realizing quality improvement through test driven development: results and experiences of four industrial teams. It is expensive to do this in a sensible way, since it basically means you need to develop the same software twice (or ideally even more often) with similar teams, and ...


23

Done well, developing with unit tests can be faster even without considering the benefits of extras bugs being caught. The fact is, I'm not a good enough coder to simply have my code work as soon as it compiles. When I write/modify code, I have to run the code to make sure it does what I thought it does. At one project, this tended to end up looking like: ...


7

It depends on the person, as well as the complexity and shape of the code you're working with. For me, on most projects, writing unit tests means I get the work done about 25% faster. Yes, even including the time to write the tests. Because the fact of the matter is that software isn't done when you write the code. It is done when you ship it to the ...


129

The later you test, the more it costs to write tests. The longer a bug lives, the more expensive it is to fix. The law of diminishing returns ensures you can test yourself into oblivion trying to ensure there are no bugs. Buddha taught the wisdom of the middle path. Tests are good. There is such a thing as too much of a good thing. The key is being ...


0

I have seen the approach of adding a default constructor that calls the parameterized constructor with default instances, i.e. "poor man's dependency injection". public OrderWriter() : this(new TextFileWriter()) { } The regular code path calls the default constructor, whereas the unit test initializes using the custom constructor. If anyone could ...


0

Commonly the clean-up of a unit test is called the tear-down, which doesn't lend itself particularly well to this case but you could call them untorn-down. In C# there is the concept of the IDisposable interface whereby the Dispose method is called to clean up unmanaged resources. You could appropriate this terminology and say that such tests are undisposed....


0

This question is related to the classic problem of balancing between spaghetti and lasagna code issues. Having multiple asserts could easily get in the spaghetti problem where you do not have an idea what the test is about, but having single assert per test could make your testing equally unreadable having multiple tests in a big lasagna making the finding ...


2

In addition to the other answers, there's another benefit to making these functions private and testing them via the public interface. If you gather code coverage metrics on your code, it becomes easier to tell when a function is no longer being used. But, if you make all of these functions public, and make unit tests for them, then they will always have ...


0

You do not need to declare the methods public just to Unit-test them. Unit test normally should belong to the same package where the class under testing belongs (of course, inside the different source code folder). As a result, also package private and protected methods can be accessed for testing. See Maven layout, for instance. While it may not be worth ...


3

I think you might benefit from a slight shift in the way you view unit tests. Instead of thinking about them as a way to guarantee that all your code is working, think of them as a way to guarantee that your public interface does what you claim it does. In other words, don't worry about testing the internals at all - write unit tests that prove that when ...


10

The short answer is "No". The more interesting part is why/how this situation might arise. I think the confusion is arising because you're trying to adhere to strict testing practices (unit tests vs integration tests, mocking, etc.) for code which doesn't seem to adhere to strict practices. That's not to say the code is "wrong", or that particular ...


8

Another point I like to add to Killian's answer is that unit tests run very quickly, so we can have 1000s of them. An integration test typically takes longer because it is calling web services, databases, or some other external dependency, so we cannot run the same tests (1000s) for integration scenarios as they would take too much time. Also, unit tests ...


7

I agree with @BrianAgnew and @kai, but would like to add more than a comment. While an IDedupeFiler (or whatever) should be tested through its public interface, the OP has decided there is value in testing the individual sub-routines. Irrespective of file size or line count (which is only a rough proxy count for class responsibilites), the OP has decided ...



Top 50 recent answers are included