Tag Info

Hot answers tagged

9

Acceptance tests act at a very different level than, say, unit tests. A unit test is very precise: it deals with one method, sometimes a part of a method. This makes it a perfect choice for regression testing. You make a change. A test fails while it passed during the previous commit. Great, you can easily pinpoint the source of the regression both in time ...


7

The problem you may quickly hit is that in order to test a particular piece of code, you should make testable the code surrounding it. Changing the surrounding code requires testing as well, which, in turn, requires even more changes. Practical example. A year ago, I had to work on a... let's call it legacy system. Millions of lines of C# code. ...


3

Implementing the "cheap" solution first is a good idea, not just because it forces you to write tests that cover all expected behaviour, but also because it sometimes ends up with you writing a simpler solution than you might have in your head. A good example of this is given in the book Beautiful Code, describing the FIT testing framework. This system ...


2

I think your problem arises only because the requirement is very simple and the solution comparing all 3 values at once maybe just a one-liner. Having slightly more complex requirements, and it will perfectly make sense not to implement anything beyond the scope of the already implemented test cases. Nevertheless, your "cheap approach" has indeed one ...


2

I would like to say that the refactoring phase in the TDD cycle is the second most important step, and the one that make the switch from simpler and cheap to intended code. The most simple example I can think of is a constructor. My first test can be that my new class receives a certain parameter and check the value of a parameter. That's pretty easy to ...


2

BDD actually started at the class level. JBehave was originally intended to be a replacement for JUnit. The only meaningful difference between JBehave and JUnit back in 2004 was the removal of the word "test", and the use of "should" to drive out different aspects of behaviour of the class and encourage questioning of those aspects of behaviour ("should ...


1

There are several testing-related questions: Which parts to test? Units (unit testing), whole system (functional), several systems together (integration) Which aspects to test? Functionality, performance, reliability, security, etc. When to do testing? Before (TDD/BDD) or after (non-TDD/BDD). Or never =) How deep to test? Or, how to view the system under ...


1

A lot of this boils down to what is "cheap, useless and ... little effort as possible." Here's another simple example: Write a function that returns the result of two numbers added together. Test: check func(2, 2) = 4 // Simple: func(a, b) { return a + b} I would like to think this is the first strategy I would take. Seems simple enough to me, but ...


1

You have to mock or emulate, and you have two very good reasons to do so. First of all, you have to mock or emulate whatever parts of the system your code interacts with, precisely because you don't want to alter the system, and you don't want your tests to depend on something as uncontrollable as the system. Yes, your emulation will not be perfect; yes, ...



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