Tag Info

Hot answers tagged

21

You're going to find yourself writing a lot more tests, of much more complicated, interesting, and useful behavior, if you can do so simply. So the option that involves var input = new Parser().ParseStatement("x = 2 + 3 * a"); is quite valid. It does depend on another component. But everything depends on dozens of other components. If you mock something ...


10

The advertised cycle of TDD is write tests until they fail then hack at the code until they pass again and then refactor while keeping all test succeeding. When the spec changes you will need to remove the old tests that would verify a violation of the new spec and write new tests that will verify the new spec.


8

I've had contractors who have left after creating a database layer with a set of unit tests which passed, but didn't actually save anything to the database so everything was lost if you restarted the system. So test the parts of your system you want to work by writing tests which compare the expected behaviour with the real behaviour. If those parts are ...


6

Of course it is OK! You always need functional/integration test that exercise the complete code path. And complete code path in this case means including evaluation of the generated code. That is you test that parsing x = 2 + 3 * a produces code that if run with a = 5 will set x to 17 and if run with a = -2 will set x to -4. Below this, you should do unit ...


5

You are over-thinking the "one assertion" rule/guideline. The reason for the rule is that a test case should test only one "behaviour" of a class. By testing only one behaviour per test case, you make it much easier on yourself to pinpoint where an error got introduced when a test case starts failing. The problem is that it is hard to tell when that basic ...


5

The common approach is to put each independent test in its own test method. The main reason for this is to make the list of passing/failing tests as self-documenting as possible. Ideally you should be able to look at which test failed and have a good idea what is wrong with the code from that alone. If single test methods test multiple things, this is not ...


4

Unit tests allow you to pin point specific items that break and where in the code they broke. So they're good for very fine grained testing. Good unit tests will help decrease debugging time. However, from my experience unit tests are rarely good enough to actually verify correct operation. So integration tests are also helpful to verify a chain or ...


4

I understand you are leaving some details out due to the proprietary nature of the project. This answer is my take on what is going on based on how I understand the question. Please leave a comment if I am off base here and I will edit accordingly. I think you may misunderstand how to use JUnit in complex projects. Each test needs to stand on its own: ...


4

I think there's not much more, you might be "close" to the complete picture (at least the picture that I'm aware of), so I'll give you a list of buzz-words. no testing: Don't use! test-last: old crap from the past, like doctors not washing their hands or accountants attempting to skip double-entry book keeping. Better than no testing, but still don't use. ...


3

TDD "by the book" has a specific cycle, and specficially for changing specs, this cycle should ideally look like this: write one test according to the new spec (-> "red") change the SUT ("subject under test") to match the new test; depending on the change, this might break some old tests (-> the new test goes "green", but the old tests become "red") Change ...


3

Treat them as an ordinary database. When you are testing business code which uses a database, you mock the database in order to test just the business code (as well as for making tests slightly faster). The same applies to key-value stores. What you may have seen is: Either integration and system tests which, indeed, rarely use mocks. Usually, a system ...


3

Above all, you need to have and analyse combined (total) coverage. If you think of it, this is the most natural way to properly prioritize your risks and focus your test development effort. Combined coverage shows you what code is not covered by tests at all, ie is most risky and need to be investigated first. Separate coverage reports won't help here, as ...


2

You don't mention your testing tool. Many have "combine" functions that let you aggregate the results of multiple runs or suites. If you want an aggregate coverage metric, explore the combine feature in your coverage tool. Now, can we talk about the elephant in the room? There is no spoon. And there is no "total coverage percentage." At least, no simple ...


2

An alternative approach is two tests, one for each component of your reset function. Or more, if you have more. These would be pretty simple to create. A key point of tests is to know what is failing when something fails. If you test the "reset" method and it fails you want to know what failed. While not super important in your example, other situations ...


2

Unit tests should cover logic, and as a matter of fact, reset doesn't contain any logic - there is no ifs, no switches, no loops in it - basically, no conditional statements of any type. And yes, it means that testing it sort of boils down to testing JavaScript as such, as you say. Set a, b, and c to empty strings! Have a, b and c been set to empty strings? ...


2

Unit tests are essentially tests of a single component. With perhaps some mock objects to fake some interfaces used by the module. You are testing that for a given input you receive the expected output. If you test involves other modules components or services which cannot be mocked then it is no longer a unit test. As such they are very useful. You can ...


1

You are using phrases like "all the interesting graph structures" and "handled appropriately". Unless you have ways to test your code against all of those structures and determine if the code handles the graph appropriately, you can only use tools such as test coverage analysis. I suggest you start by finding and testing with a number of interesting graph ...


1

Mocking serves a number of purposes: make the test run fast make sure all services required by the test are always available make sure defects don't make debugging your module too complicated If none of these is a substantial problem in your case, don't mock. Why not? Because creating mocks costs time mocks induce additional effort when changing your ...


1

My opinion is that you should do nothing, meaning you should not add any new tests. I stress that this is an opinion, and it actually depends on the way you perceive the expectations from the object. Do you think the user of the class would like to supply a strategy for tax calculation? If he doesn't care, then the tests should reflect that, and the ...



Only top voted, non community-wiki answers of a minimum length are eligible