Tag Info

New answers tagged

7

Am I doing it is right? If not what exactly I have to change It's hard to say just from that short description, but I suspect that, no, you are not doing it right. Note: I am not saying that what you are doing doesn't work or is in some way bad, but you are not doing TDD. The middle "D" means "Driven", the tests drive everything, the development ...


2

Writing tests first is a completely different approach to writing software. Tests are not only a tool of proper code functionality verification (they all pass) but the force that defines the design. While test coverage might be a useful metric, it must not be the goal in itself - the goal of TDD is not to get to a good % of code coverage, but to think about ...


5

You describe your development approach as a "top-down-only" process - you start from a higher abstraction level and go more and more into the details. TDD, at least in the form as it is popular, is a "bottom-up" technique. And for someone who is working mostly "top-down" it can be indeed very unusal to work "bottom-up". So, how can you bring more "TDD" ...


3

Am I doing it is right? If not what exactly I have to change You're doing just fine. Is there any way you can identify whether test you have written are enough? Yes, use a test/code coverage tool. Martin Fowler offers some good advice on test coverage. Is it good practice to writing test for very simple functionality which might be equivalent ...


-1

1. The most important thing is to have well-structured code with good coverage by unit-tests. In most cases you can happily do it following TDD approach, sometimes it's easier to follow code-first-then-test approach. You should be flexible about it. You've just not done with the task until you have tests for it. Sometimes, when starting development of a ...


0

What's the idea behind mocking data access in unit tests ? - The speed of tests. It's certainly true that you don't need to test the database, file system or other external dependency, but in reality it's often not that hard to set up the database, etc. and the actually code works aginst it so it's really easy to just use the database and it is closest to ...


4

When you are testing a unit of code (say a single method or class), you want to only test that unit and have no other dependencies (with possibly unknown state). If you don't use mocks in unit tests, you are putting yourself in a position of uncertainty - if a class your method/class depends on changes, it can break your test even though your code has not ...


5

Because hitting a database is slow, requires an elaborate environment set up just right in order to work, and spends most time in code not written by you. A unit test is supposed to test your code, not Oracle's code. 2./3. No, you don't replace mocked things with real things. You leave mocked collaborators in your testing code, and then you don't ship ...


4

TDD is primarily an implementation technique, so it works as orthogonal as writing other code to the "graphical" design techniques you mentioned. (If the latter techniques are used in all software companies, for all kind of professional software, is a completely different question.) When you have UML diagrams on the abstraction level of your public class ...


1

Why does TDD work? It doesn't. Clarification: automated tests are better than no tests. However I personally think that most of unit tests are waste because they usually tautological (i.e. says things obvious from actual code under test) and it can't be easily proven that they consistent, not redundant and cover all border cases (where errors usually ...


1

As you now describe it, I agree with your lead. What you need to test about your method is that it passes the correct predicate to the repository. What the repository does with the predicate belongs in a test of the repository unit.



Top 50 recent answers are included