Tag Info

New answers tagged

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


-1

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.


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


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


0

What is a good strategy for generating the underlying data for the tests? I would use a modified version of the second approach: Generate fake data such that for each request X there is a well-defined, intentionally constructed set of results Y that will be returned. But instead of querying the database directly your searchengine should be ...


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


0

It's not clear to me what you try do, it can be one of two very different things that you want to test, and you should not conflate them together: Test that something is not awfully broken with your system - i.e. "write testcases". In this case, it's best if you generate some fake (probably relatively small) corpus of documents that you index, and write ...


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


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


-1

As much as possible try and make your classes as independent as possible during unit testing, keeping cross referencing of functions down to a minimum will help in debugging, after all unit testing is done you could then create standalone utility functions that can handle operations that will be cross referenced by your classes...


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


0

Mocking data is just the practice of using dummy data.. the Moq frameworks make creating dummy data "easier". ARRANGE | ACT | ASSERT TDD generally is about creating your tests and then validating those tests "pass". Initially, the first test will fail since the code to validate that test has not been created yet.. I believe this is actually a certain type ...


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



Top 50 recent answers are included