New answers tagged

2

Say it's broken. Say you're thinking about something else entirely and don't have a lot of patience for this bug. Which test do you wish had been written now? I test as much as I can get away with. At some point you have to stop and get paid. Keeping that in mind, it's not simply behavor. It's the boundaries. Your behavor is 'show me the neighbors'. ...


7

You can do two things: First, use parameterized tests to minimize the duplication of the test code: cases([ [0, [1, 8, 9]], [1, [0, 2, 8, 9, 10]], // more testcases here ]) .it('sample', function(n, expected) { expect(getNeighbors(n)).toEqual(expected); }); Second, partition your testcases into equivalence classes where ...


3

The key here is your perspective on a particular function as trivial. Most of programming is trivial: assign a value, do some math, make a decision: if this then that, continue a loop until... In isolation, all trivial. You just got through the first 5 chapters of any book teaching a programming language. The fact that writing a test is so easy should be a ...


1

Should savePeople() be unit tested, or would such tests amount to testing the built-in forEach language construct? This has already been answered by @BryanOakley, but I have some extra arguments (I guess): First a unit test is for testing the fulfillment of a contract, not the implementation of an API; the test should set preconditions then call, then ...


5

Should bakeCookies() be tested? Yes. How should a function like this be unit tested, assuming you think it should? It's hard for me to imagine any kind of unit test that doesn't simply mock dough, pan, and oven, and then assert that methods are called on them. Not really. Look closely at WHAT the function is supposed to do - it is supposed to set the ...


11

Should savePeople() be unit tested Yes, it should. But try to write your test conditions in a way that is independent from the implementation. For example, turning your usage example into a unit test: function testSavePeople() { myDataStore = new Store('some connection string', 'password'); myPeople = ['Joe', 'Maggie', 'John']; savePeople(...


1

You should also test bakeCookies - what would/should e..g bakeCookies(egg, pan, oven) yield? Fried egg or an exception? On their own, neither pan nor oven will care about the actual ingredients, since none of them are supposed to, but bakeCookies should usually yield cookies. More generally it can depend on how dough is obtained and whether there is any ...


1

I think your question boils down to: How do I unit test a void function without it being an integration test? If we change your cookie baking function to return cookies for example it becomes immediately obvious what the test should be. If we have to call pan.GetCookies after calling the function though we can question whether its 'really an integration ...


12

The primary value such a test provides is that it makes your implementation refactorable. I used to do a lot of performance optimizations in my career and often found problems with the exact pattern you demonstrated: to save N entities into the database, perform N inserts. It's usually more efficient to do a bulk insert using a single statement. On the ...


92

Should savePeople() be unit tested? Yes. You aren't testing that dataStore.savePerson works, or that the db connection works, or even that the foreach works. You are testing that savePeople fulfills the promise it makes through its contract. Imagine this scenario: someone does a big refactor of the code base, and accidentally removes the forEach part of the ...


29

Usually this kind of question comes up when people do "test-after" development. Approach this problem from the point of view of TDD, where tests come before the implementation, and ask yourself this question again as an exercise. At least in my application of TDD, which is usually outside-in, I'd not be implementing a function like savePeople after having ...


2

Should savePeople() be unit tested, or would such tests amount to testing the built-in forEach language construct? Yes. But you could do it in a way that would just retest the construct. The thing to note here is how does this function behave when a savePerson fails half way through? How is it supposed to work? That is the sort of subtle behavior that ...


3

To make it simple: Static state is bad because it is effectively global state since everyone has access to it. Wrapping it in a singleton doesn't change anything. In general it is good to avoid global state which is hard to test. Static functions that are pure functions or that only mutate their arguments are perfectly fine. If they don't do any ...


6

The notion that static methods are impossible to unit test is a myth that has proven difficult to kill. What makes a method hard to test in isolation is stuff like hidden dependencies and accessing static state. There is no difference whatsoever between a static method and an instance method, except for the fact that invocations of instance methods get a ...


0

This is a Java-specific design. For example in D, sort is an instance method on arrays, not a static method as in Java. But in Java arrays are special. They are defined as objects, but they are not instances of classes. The only instance methods they have are the ones inherited directly from Object. There are no Array-specific instance methods since there ...


0

Trusting the dependent class that it works properly, hoping there would fail some unit tests when something there does not work, then it should this be tested very vell. Maybe there are missing some important unit tests? There can be an untested case that would create an error, that will be produced in my originary testing class, and would not be catched in ...


0

I have seen the approach of adding a default constructor that calls the parameterized constructor with default instances, i.e. "poor man's dependency injection". public OrderWriter() : this(new TextFileWriter()) { } The regular code path calls the default constructor, whereas the unit test initializes using the custom constructor. If anyone could ...


2

It absolutely makes sense. Agile is not about testing, as others have mentioned already, but to specifically answer your question: No, you do not need unit testing at all. You can run an agile process with integration testing only. You could run an automated integration test nightly for example and fix bugs that are found the next day. You could have a ...


1

As a general, largely language agnostic approach, any time you're concerned that the behavior of a third party library might change, the providing of that behavior (be it your own code in the future, or another third party library) might change, or you simply want to decouple the third party library, it's perfectly reasonable to build a more abstracted ...


1

It's not required. Testing is great when you have people that really know how to use it. When you don't, not only is it not necessary, it becomes a liability. I'd say there are many programmers who are not very skilled at it. I'm glad you acknowledged in your question that being agile is about how you actually release software instead of following some ...


7

Even though that there's no direct word stating about unit testing or TDD or any kind of test in the agile manifesto as others have answered here, I believe that a good Scrum Master or Developer would be able to discern one of the statements in the manifesto. Working software over comprehensive documentation. How would anyone know if the software is ...


24

To be pedantic, nothing in the Agile Manifesto or the Scrum Guide make any reference to technical practices, like unit testing or TDD, at all. So, yes, in theory you could deliver early and often with a focus on collaboration and value without them and call yourself Agile, you might even actually have agility. In practice however, it's nearly impossible to ...


26

The agile manifesto simply states: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan No mention of unit tests there. Even the 12 principles do not mention testing. So, technically, it's possible to be an ...


4

Make sure you review Uncle Bob's recent comments about the role of design in TDD. Domain-driven design involves a lot of technical patterns, defining well established layers like Application layer, Infrastructure layer, Domain Layer, Persistence layer. Udi Dahan: "God, how I hate layering." He spends some time discussing it in his talk CQRS - but ...


5

Test Driven Development (TDD) is not a design. It's a requirement that impacts your design. Just as if you were required to be thread safe, that's not a design. Again, it's a requirement that impacts your design. If you gleefully ignore all other design concerns and religiously keep to the TDD rules don't blame TDD when your code turns into crap. It ...


1

TDD insures your code has all necessary test cases written in parallel to development. This shouldn't effect high level design. Think of it more in the trenches work. DDD is all about high level designs, language between domain experts & engineers, context mapping, etc. This should be the driver of the application high level design. These are both ...



Top 50 recent answers are included