Tag Info

Hot answers tagged

26

To verify if you have enough tests or not, you can check your code coverage and your branch coverage induced by the tests (maybe by using a coverage tool, maybe manually by reviewing the code paths or by using a debugger). If you come to the conclusion the tests for the subclasses give you a high enough coverage for your base classes code, then adding ...


4

The point of TDD from a business perspective is really not so much reducing bug-fixing time. You do reduce the maintenance effort, but you spend more time fixing defects while you write the code in the first place, because you never get things entirely correct on the first try (if you could, you wouldn't testing at all). Sometimes one effect predominates, ...


3

@CarlManaster has the right idea: It's the responsibility of the developer to: write a unit test, verify that it fails, implement it, verify that it succeeds, refactor the feature without failing the test, and finally refactor the test code for every feature. The reason for each of these can be summarised as follows: Writing the test before the code ...


3

Run your unit tests on every branch. How do you know your code is actually working as expected otherwise? This goes the same for any other tests you may have. You say it yourself right here, "If they only run on the develop branch and a feature branch going on for long, I am afraid that the developer is pushing changes to his feature branch which would ...


3

Short-term solution: Leave things as they are. Badly written, brittle tests are much, much better than not having tests. On a scale from "no tests" to "tests so reliable they make you weep and do all your work for you", your existing test suite is much closer to "weep" than to "nothing". Middle-term solution: refactor. It's inconceivable that the analysis ...


3

If the current requirements are that after login, you must always navigate to the screen indicated by the constant NavigableScreens.MyNextScreen, then that most likely isn't a dependency that should be injected. It is just a value that you pass on to another function anyway. However, NavigationManager looks to be a class with a fair bit of functionality in ...


2

You're right, usability testing has a very different purpose. It consists of asking a user to manipulate a part of your product, and look at the way the user tries to achieve something. The goal is to ensure that user experience of your product is right and if there are things which could be improved to make the product easier, more intuitive or faster to ...


2

One perspective is that you always need a justification to mock, rather than a justification to use the real dependency. Mocked tests are, simply put, worse than real tests; they test less require more maintenance are harder to write produce both false positives and false negatives have results that are more difficult to interpret run slower (may vary ...


2

A good guideline is that your tests should exercise all the code that you've written. If different inputs cause different code paths to be executed, it is a good idea to choose your test inputs so that every path is covered. More thorough testing also tries to ensure that every path is covered under different circumstances, particularly with extreme ...


1

Automated test were created for the programmers benefit, programmers were not created to serve the tests. We have tests to make us more productive and to reduce the number of “issues” customers complain about. So given that you have behaviour oriented unit tests covering all of the cases in each subclass, there is no benefit to the customer of you ...


1

Directly testing your own code is good form, and a system that encourages someone other than the developer to test it is a hazard, as the code may not even be testable without heavy modifications. That said, expanding a project's unit test suite is a great way to get yourself on board with now it works. TDD style test first coding works very well in a ...


1

Should unit tests run on every git branch? This one is an easy one. The main point of doing continuous integration is to detect errors as early as possible in the build process. From this it should be clear, that you should a) run a testsuite on every branch of your code b) do not allow checking in code, which neither runs nor passes all tests ...


1

The underlying problem that you are encountering is that you are testing everything in one go when comparing two text files. If any little thing changes, then the entire test fails and it is indeed tedious to find the part that broke and then fix it. You are doing system testing in jUnit. Not that it can't do it (though there are better testing frameworks ...


1

If the format of the log changes at all, it will break the unit tests When code changes, it breaks the corresponding unit tests. By following your logic to the extreme, you would avoid writing tests at all. Think about the goal of those tests. Are you testing: That a method actually logs something? That a method uses a proper message template? That a ...


1

Traditionally in BDD we'd start with the outside and move in, so we'd have a web page, then from there move to the actual DB connections until the scenario worked with the web page. However, your question about whether you can use the same feature file with different steps at different levels is appropriate and applicable. I don't think at the moment that ...



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