Tag Info

Hot answers tagged

12

I think it's natural to encounter a divide within unit testing. There are many different opinions on how to do it properly and naturally all other opinions are inherently wrong. There are quite a few articles on DrDobbs recently that explore this very issue to which I link at the end of my answer. The first problem I see with tests is that it's easy to get ...


7

Factors Limiting Industrial Adoption of Test Driven Development, a research paper from 2011, reviewed 9,462 papers on TDD, and included 48 studies as a basis for their research. The paper covers the topic of why TDD may not be used in depth, but for ease of reference, here's a summary: Development time: Development time could be considered a ...


5

You're right when you tell that you may use the first approach before refactoring. While personally, I disagree with this approach, that's the rule of three from Refactoring by Martin Fowler (page 58): Here's a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the ...


5

I believe it is important to have tests of both types and to use them where appropriate. Like you said, there are two extremes and I honestly do not agree with either one as well. The key is that unit tests have to cover business rules and requirements. If there is a requirement that the system must track a person's age, write "trivial" tests to ensure the ...


4

My own answer/realization: From fixing various errors while refactoring I am realizing that I wouldn't have done the code moves as easily without having tests. Tests alert me of behavioral/functional "diffs" that I introduce by changing my code. You don't have to be hyper aware when you have good tests in place. You can edit your code in a more relaxed ...


3

Here's my take on it: all tests have costs: initial time and effort: think about what to test and how to test it implement the test and make sure it's testing what it's supposed to ongoing maintenance making sure the test is still doing what it's supposed to do as the code evolves naturally running the test execution time analyzing the results We ...


3

I think it all comes down to a simple question: Does it have to work? If it does, then I would say it is best to do TDD, on the majority of cases. To me, the exceptions are very lightweight pieces of code. Weight the effort of manually testing every single procedural branch in the code. If this effort is smaller than that of writing automated tests, then ...


3

.aspx files, compared to corresponding .aspx.cs code-behind files) are expected to contain minimum programming code, i.e. large chunks of HTML with here and there the calls to variables, eventually with straightforward loops and conditions. This means that you will rarely find unit tests for .aspx files, since there are no complicated algorithms or business ...


2

There are few types of unit testing: State based. You act and then assert against state of the object. E.g. I make a deposit. I then check to see if balance has increased. Return value based. You act and assert against return value. Interaction based. You verify that your object called another object. This seems to be what you are doing in your example. ...


2

At the risk of swimming against the tide, I solved this exact problem a number of years ago using a method not so far mentioned. My strategy was simply to mock the RNG with one that produces a predictable stream of values spanning the entire space. If (say) side=6 and the RNG produces values from 0 to 5 in sequence I can predict how my class should behave ...


2

After watching this amazing talk "Ian Cooper: TDD, where did it all go wrong", I'm going to disagree with @pdr. I think you should only keep the original tests. Your ability to refactor your system under test without breaking, writing or changing any tests is the whole purpose of writing tests in the first place. If I were to test the extracted class, ...


2

TDD is not design - it is a design process. A main artifact a TDD process eventually give you is the unit test suites, which should (to some degree) attest to the actual code's scope and capabilities. Good test suites give some assurances that the code works, and added security that future code changes can be done without breaking past code, as failing ...


2

Your specific example is a case that you usually have to test by checking if a certain method was called, because saving X to data source means communicating with an external dependency, so the behavior you have to test is that the communication is occurring as expected. However, this isn't a bad thing. The boundary interfaces between your application and ...


2

You are talking about performance, which is essentially an Non Functional Requirement. My view is that most of these are for the whole system. A user is never going to say "I want the WidgetListCollection class to return a widget within 20 nanoseconds" -- he might say "I want a list of all products on my screen within 1.5 seconds". The only way to ...


2

I generally write enough tests to give me confidence that my implementation is correct, but no more than that. How many tests this is depends on the problem at hand. If you're feeling very unsure about the correct implementation of the behaviour, you'll probably end up writing a full set of tests for each endpoint and refactoring at the end: going from ...


2

What is a unit test, really? And is there really such a big dichotomy in play here? We work in a field where reading literally one bit past the end of a buffer can totally crash a program, or cause it to produce a totally inaccurate result, or as evidenced by the recent "HeartBleed" TLS bug, lay a supposedly secure system wide open without producing any ...


1

As long as the functionality you'd like to test doesn't invoke any pure virtual methods and isn't overridden in subclasses, I'd stick with your bullet point number 1 - creating a test-specific subclass. You could name it Sub<ClassName> or any generic name reflecting that the subclass itself is not important. Now if what you want to test can be altered ...


1

You could do the following: create an abstract base class with only pure virtual methods, for example AmazingObjectInterface; add a subclass called BasicAmazingObject that defines the non-virtual methods that you need to test; finally, your 2 original subclasses becomes subclasses of BasicAmazingObject. This allows you to separate what varies and test ...


1

My guiding principle here would be that test code has to meet the same level of quality as implementation code. If your test code can't reach that level, then something is wrong with the implementation design. In the specific context of a method that is now common to two classes, I would try to refactor that into a common class that both Class1 and Class2 ...


1

This is of course, just my oppinion, but having spent the last few months learning functional programming in fsharp (coming from a C# background) has made me realize a few things. As the OP stated, there are typically 2 types of "unit tests" we see day to day. Tests that cover the in's and out's of a method, which are generally the most valuable, but are ...


1

How do people/companies handle this type of test? There are many kind of testing, but your interests are unit and functional : unit tests - needs to be very fast, in order to be execute on every change in the code. Their purpose is to test modules. functional tests - they are similar to unit tests, except they do not need to be fast. They are ...


1

You could do either, so this is primarily opinion based. If you start with the backend, though, you should have unit tests, certainly, but also some sort of test harness that can simulate whole-flow calls to the backend. If you start with the GUI, you should have stubs or mock implementations of the backend to test your GUI against. Don't create a real GUI ...


1

My interpretation of that talk is: test components, not classes. test components through their interface ports. It's not stated in the talk, but I think the assumed context for the advice is something like: you are developing a system for users, not, say, a utility library or framework. the goal of testing is to successfully deliver as much as possible ...


1

What is the goal of refactoring in your specific case? Presume for the purposes of putting up with my answer that we all believe (to some degree) in TDD (Test-Driven Development). If the purpose of your refactoring is to clean up existing code without changing existing behavior, then writing tests before refactoring is how you ensure that you have not ...


1

From a testing perspective there are some requirements that are an absolute must: Testing (unit or otherwise) must never have a way to touch production data The results from one test must never affect the results of another test You must always start from a known position That's a big challenge when connecting to any source that maintains state outside ...


1

TL;DR - The way I see it, it depends on how much effort you end up spending on tests, and whether it would have been better to spend more of it on your actual system instead. Long version: Some good answers here, but my take on it is different: testing is an economic activity that needs to pay back for itself, and if the time you spend isn't returned in ...


1

What is a Die if you think about it ? - no more than a wrapper around random. It encapsulates random.randint and relabels it in terms of your application's own vocabulary : Die.Roll. I don't find it relevant to insert another layer of abstraction between Die and random because Die itself is already this layer of indirection between your application and the ...


1

In my experience the biggest problem with TDD is the "T". It causes the lay-person (managers, testers, non-TDD devs) to equate it in their minds with the traditional post-development "Testing" phase of a waterfall style. That is something that anyone can get their head around. The problem that many struggle with is that TDD is for developers, not testers. ...


1

When faced with a philosophical quesion, drop back to the driving requirements. Is your goal to produce reasonably reliable software at a competitive cost? Or is it to produce software of the highest possible reliability almost regardless of cost? Up to a point, the two goals of quality and development speed/cost align: you spend less time writing tests ...



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