Tag Info

New answers tagged

1

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 ...


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 ...


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 ...


0

by it's very nature, actually must break the unit test? Yes. That is the exact purpose of the Unit Test, So you have to change your tests and then verify if the new changes are meeting your test.


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.


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 ...


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 ...


3

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: ...


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 ...


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 ...


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 ...


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 ...


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. ...


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 ...


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 ...


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 ...


0

This is where you have to apply a combination of dependency injection and mock tests. You would test the service and controller & view separately. Do this by mocking the service to return a recorded value and then test if you controller end up with this recorded value. TDD is unit testing. You shouldn't test the coupled configuration (which is ...


2

Whenever you test a class or a method, you provide the inputs and then verify that it produces the outputs that it is responsible for. If the documented behaviour of your class is to pass on whatever it gets, then you would write a test passing in "foo" and "bar", or "grumpy" and "slouchy", or any other set of inputs, and verify that they are passed on. The ...


3

My first reaction of this question is “it depends”. It depends on what you mean by “development team test cases”. If you have only unit tests (white-box test); QA Team (integration and system test) could not leverage your test-cases. Unit test are only there to verify your unit, which solely don’t satisfy a requirement (mostly). White-box testing ...


4

In a modern software architecture the intent is that the tests not only test the code but they do so in a way that documents their functionality. This documentation of what the code does (in addition to what it is intended to do in the specs) is useful for QA'ers to better understand the intent of the code and also whether it matches the requirements. It ...


0

There's no reason that you shouldn't share what you've tested with the QA team, however they should be duplicating the tests of yours that they feel are important to properly verifying the application. 1) They are responsible for testing the code/application/whatever. By duplicating your tests where appropriate, they verify that your test was done properly. ...


16

Testing team (the so called QA team in some organization) insists that the dev team should share their (Dev team's) test cases with them. Sure, QA should have a general understanding of what is covered by unit/integration tests, and what is not. Their arguments are Dev test cases are the starting point for the QA testing. ...even if their ...


19

When your dev team and your QA team don't not talk to each other, there is a certain risk that some tests are unnecessarily done twice, and some others are forgotten. One worst case scenario is when your dev team has implemented some nice automatic integration tests, which run in a few minutes or hours, and your QA people tests the same things manually, ...



Top 50 recent answers are included