Tag Info

Hot answers tagged

14

if in TDD in theory you have to write first your test suit and build your code up from it Here is your misunderstanding. TDD is not about writing a full test suite first - that's is a false myth. TDD means to work in small cycles, writing one test at a time implement only as much code as needed to make the test "green" refactor (the code and the ...


12

What stumbles my mind is that... if in TDD in theory you have to write first your test suit and build your code up from it, how am I supposed to know beforehand that in order to perform my operation I'll need to use those three dependencies and that the operation will call certain operations? It's like I need to know the innards of the Subject Under 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.


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


4

While TDD is a test-first method, it does not require you to spend a lot of time writing test code before you write any production code. For this example, the idea of TDD described in Kent Beck's seminal book on TDD (1) is to start with something really simple, like maybe AccountController controller = new AccountController() var result = ...


3

You may eventually need all this complexity for a conceptually simple unit test, but you will almost certainly not write the test like this in the first place. First of all, the complex set-up in your first six lines should be factored out into self-contained, reusable fixture code. The principles of maintainable programming apply to test code just like ...


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


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


2

It's like I need to know the innards of the Subject Under Test before even implementing it in order to Mock the dependencies and isolate the class, creating some kind of write test - write code - modify test if necessary cycle. Yes, to some extent you do. So I don't think you're misunderstanding how TDD works. The problem is that - as others have ...


1

Short answer: you need both fake data, with well defined input X and output Y real-world data, probably with the modifications you suggested Use the first one especially when doing TDD (as your tag indicated), and after you have the basic algorithm ready, use the second kind of data for integration or acceptance tests. The first kind of tests will ...


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


1

Contrary to the other answers, it is important to note that some ways of testing can become fragile when the system under test (SUT) is refactored, if the test is whitebox. If I'm using a mocking framework that verifies the order of the methods called on the mocks (when the order is irrelevant because the calls are side-effect free); then if my code is ...



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