Tag Info

New answers tagged

0

Just to keep it confusing, realize that a lot of people now associate BDD with cucumber. They consider any tests you write using gherkin-derived syntax to be a BDD check, and anything written using a unit test framework (junit, unittest.py, etc) to be TDD. It's wrong. The medium doesn't define the message in this case. Nor does the use of mocks (IMHO). ...


0

Sometimes I use option 4 Use the strategy pattern. Create a utility class with static methods that delegate implementation to an instance of pluggable interface. Code a static initializer that plugs in a concrete implementation. Plug in a mock implementation for testing. Something like this. public class DateUtil { public interface ...


0

BDD adds one more level of abstraction to the tests. The higher level code (usually in txt) describes what the system tests, the lower level code describes how it tests it. So a BDD framework can use a TDD framework in the lower level code. This helps a lot by staying DRY. By TDD you can easily end up with "wet" tests containing a lot of code duplication, ...


3

Despite the other answers to this question, there is in fact a lot of behaviour in this method, and therefore a lot of things that could go wrong if we don't test them. Here are the cases I would check: When view is not empty and data is not empty, then both view and data are set in the Crashlytics object. This test is sufficient to get statement coverage. ...


4

The point of unit testing is testing your code's functionality in isolation. To the extent that your code is simply a wrapper around an external library, it doesn't really have any functionality to unit test. It may be useful to unit test the NULL and nil values, as you suggest. However, unit testing the call to the library doesn't seem worthwhile. ...


1

I would actually... not go for both, but I'll pick yours over your co-worker for your simplified example. First things first, I tend to favor inlining values instead of doing one-off assignments. This improves code readability for me as I do not have to break my train of thought into multiple assignment statements, then read the line(s) of code where they ...


2

It depends. In general, having repeating constants declared in only one place is a good thing. However, in your example, there is no point in defining a member VALID_NAME in the shown way. Assumed in the second variant a maintainer changes the text name in the first test, the second test will most probably be still valid, and vice versa. For example, lets ...


7

You should keep doing what you're doing. Repeating yourself is just as bad an idea in test code as in business code, and for the same reason. Your colleague has been misled by the idea that every test should be self-contained. That's quite true, but "self-contained" doesn't mean that it should contain everything it needs within its method body. It only ...


0

The Red-Green part of the cycle tests the test. If you have a hunch that a particular edge case needs to be considered, or just to show that it's been accounted for, I'd argue it's legitimate to artificially force a failure to prove that a test locks the implementation into a correct behavior. In the example case, it's probably unnecessary. But, if you ever ...


0

Mocks are acceptable in this case, but you don't need it. Instead of unit testing method(), instead unit test just the portion that handles the response. Extract a function that takes ResponseData (of whatever kind is appropriate) and then performs the action. Instead of mocking, now you just construct a ResponseData object and pass it in. You can leave ...


0

What I've done, and it works: Have all code call webservices through proxy. The proxy calls a class that statically knows if we are using proxy or not and redirects accordingly. Mocks are just HashMaps that for each request returns a given reply. Run the tests several times in this order: 3.1 First all webservices are tested. From each machine, even ...


0

What I have done in the past is use Acceptance Test Driven Development. ETL code is often distributed across different stages/languages and technologies AND tightly coupled. Most ETL process are dependent on the sequence of transformations in the pipeline. The risk in using unit test only in ETL is that it won't cover the integrations. The sequencing of ...



Top 50 recent answers are included