Tag Info

New answers tagged

5

There are many cases where you write a test that is not simply the answer to a question. Compare 'does the controller send a notification mail' with 'controller should send notification mail'. Both are valid, but it is much easier to read a list of tests formulated as 'should' rather than formulated as questions. Another major point in TDD is that the test ...


3

BDD style tests (as might be the case with the framework you're using) follow the Given-When-Then convention, not Question-Answer. Depending on the approach prescribed by your testing library, shoehorning questions in there might feel awkward. However, questions could fit well in more classical test schemes where the test description is entirely contained ...


3

Ideally, you want both unit tests (which test individual functions) and integration tests (which test all the functions together), not just one or the other. You will also need a way to mock out the web service you're calling so that these tests don't depend on it. To directly address a few of the sub-questions: So is correct to create a big test that ...


1

Two things could help you there: Instead of Use Cases, User Stories. Why? Well User Stories are written for/by the user. They are not an accurate description of functionality, but do specify what the user wants to do. This can be your initial road map into writing code that actually allows the user to do something, rather than comply with system ...


0

A test fundamentally tells you, "If I supply input X to program P, I get output Y." Test driven development works by writing X and Y first then filling in the gap. Work backwards. The program will produce some outputs. Whether these are control signals, images, web pages, text, lamps, toast, whatever: outputs. Produce some representative outputs by hand. ...


3

You cannot jump directly from "idea" to "implementation". Good example is the "V model" : You start at high level go lower and you write tests on each level. And each level gets more specific in both implementation and testing. For example you write an acceptance test that says that you should be able to add a customer. This results in you writing an ...


0

Writing use cases with (say a Product owner) could perhaps get you started. The problem for me is that "conception" in your graph and unit tests are on different conceptual levels. Unit tests are on a very low level (and are best viewed as a code design tool), they do not dictate or guarantee system level features. I would start by writing automated high ...


0

I do not like system level tests written in java or C# for that reason. Look at SpecFlow for c# or one of the Cucumber based test framework for java (maybe JBehave). Then your tests can look more like this. And you can change your object design without having to change all your system tests. (“normal” unit tests are great when testing single ...


9

This felt odd as I was forcing the design of the implementation based on how I had decided at this early stage to write this first test. I think this is the key point in your question, Whether or not this is desirable depends on whether you lean towards codeninja's idea that you should design up-front then use TDD to fill in the implementation, or ...


0

Before you start writing your tests, you should think about how to design your system. You should spend some considerable amount of time during your designing phase. If you did it, you won't get this confusion over TDD. TDD is just a development approach link: TDD 1. Add a test 2. Run all tests and see if the new one fails 3. Write some code 4. Run tests 5. ...


16

In order to write the test in the first place, you have to design the API that you are then going to implement. You've already started on the wrong foot by writing your test to create the entire GameOfLife object and using that to implement your test. From Practical Unit Testing with JUnit and Mockito: At first you might feel awkward for writing ...


0

Even when I implement something in a "hack it together" way, I still think up the classes and steps that will be involved in the whole program. So you've thought this through and written these design thoughts down as a test first - that's great! Now keep iterating through both implementation to fulfill this initial test, and then add more tests to improve ...


0

There different school of thought about this. Some say: test not compiling is error - go fix write smallest available production code. Some Say: it is OK to write test first check if it sucks(or not) ant then create missing classes/methods With first approach you are really in a red-green-refactor cycle. With second you have a little bit wider overview ...


1

Given a scenario, when some method is called the data must be persisted into db and have following steps: Setup empty db simulator (you call it mock) and pass it in as a dependency do call the method you are testing Verify the data was stored in simulator OR Setup db simulator with predefined data and pass it in as a dependency do call the method ...



Top 50 recent answers are included