Hot answers tagged

99

Testing dogmatism aside, the real question is whether it provides value to unit test complex regular expressions. It seems pretty clear that it does provide value (regardless of whether the regex is part of a public interface) if the regex is complex enough, since it allows you to find and reproduce bugs and prevent against regressions.


22

This is a wonderful idea, with one caveat. Don't replace developer written tests with reviewer written tests. Have your reviewers look for corner cases and inputs that will break the code. In other words, have them try to write new tests that the original developer didn't think to write. Writing characterization tests is an absolutely wonderful way to gain ...


21

Regex can be a powerful tool, but it is not a tool you can trust to just still work if you make even minor changes to complex regexes. So create lots of tests that documents the cases that it should cover. And create lots of tests that documents cases it should fail, if it is used for validation. Whenever you need to change your regexes you add the new ...


18

I don't think the idea is entirely without merit - however, the main benefit of the TDD et al is that problems are found early. The developer is also best placed to spot which corner cases may require specific attention. If this is left until the code review, then there is a risk this knowledge could be lost. Writing tests during the code review would ...


12

There are some posibilites, how to mock static methods in PHP, the best solution I have used is the AspectMock library, which can be pulled through composer (how to mock static methods is quite understandable from the documentation). However, it's a last-minute fix for a problem which should be fixed in a different way. If you still want to unit test the ...


7

Wouldn't it be beneficial to write tests during code review, by the person doing the review? I have found that a good time to write tests is when you realize you need a test for a situation. Task switching for computers is expensive - even more-so for humans. At this point in time, you generally have a good understanding of the requirements and ...


6

I agree with @RobbieDee's answer but I have a bit more to add. If you really like this idea, why not have the same people write the tests before the code as executable acceptance criteria for the user story? That would do the same thing, still keep the feedback short and get everyone to have a discussion around the story ,which I think would be of greater ...


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 ...


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 ...


4

First, I would suggest to split this up into separate methods: public function validate($value, Constraint $constraint) { $totalCount = QueryTotal($value); ShowMessageWhenTotalExceedsMaximum($totalCount,$constraint); } private function QueryTotal($value) { $searchEntity = EmailAlertToSearchAdapter::adapt($value); $queryBuilder = ...


4

Teamcity will tell you all of the commits that triggered the build. Get a list of names of the people making those commits, and assign the task to all of them.


3

Like you say, if you're running a TDD team, then this is moot since the code should already be tested. Overall I don't think this is all that great an idea, but it depends on your current approach and what works for you. Basically, the problem I see is that you lose the "short feedback loop" advantage of tests. Getting instant notification the moment you ...


3

Regular expressions are code along with the rest of your application. You should test that the code overall does what you expect it to do. This has several purposes: Test are runnable documentation. It clearly demonstrates what you need the code to do. If it is tested it is important. Future maintainers can be certain that if they modify it, the tests ...


2

I think that specifically for this example (distance metrics) one could check as well that triangle inequality (https://en.wikipedia.org/wiki/Triangle_inequality) holds. This would not confirm that this is indeed squared distance, but will rule out a lot of incorrect distance implementations. As well, as distances are mathematically metrics, one could ...


2

Statisticians have also looked at this issue - actually as early as in the 1970-80s. Given appropriate assumptions on how bugs are discovered they try to estimate the number of bugs from the data of the testing. This is then used to determine when to stop based on optimizing a loss function. See for example https://rpubs.com/hoehle/17920... for a short ...


2

That would be an integration test. N.B. you should be doing very few of these (if you do any at all). Hint: even if you don't call them integration tests, they're certainly not unit tests.


2

In any one test, this can be either a good or a bad thing. Most likely, it's a good thing that you can write this test at all, and it's a good thing to have a test that runs the real CreatePerson alongside the real UpdatePerson. In general, the fact that you can use a piece of production code in tests at all is already a good thing. There absolutely should ...


2

No, don't do it. You'll make them think TDD is horrid. I think @k3b has it right in the comments on the question. Code written through a TDD-style process tends to look, and interact, very differently to code written without tests. Adding (good) tests to untested code usually takes a lot of refactoring the code to clarify its intent and moving parts. By ...


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 ...


1

It depends what you are doing in code review. I think there are two main reasons for writing tests at that stage: first, if you do also refactoring during code review, and you note there are not enough unit tests to cover the kind of refactoring you want to apply, add such tests second, if the code looks to you as if it might have a bug and you want it ...


1

It is perfectly ok to use production code for your tests as long as you don't shortcircuit the test. For instance, don't do this: var expected = 4; var actual = Calc.Subtract(Calc.Add(expected, 1)); Assert.AreEqual(expected, actual); As long as you know the test fails when anything is wrong, I think it is even better to reuse production code for test ...


1

To give a different perspective on your system, you have a server that can perform a large number of validations, and next to those validations you have a (country-specific) configuration that specifies which subset of validations must be active and which subset must not be active (and that leaves a subset where you don't really care if it is active). The ...


1

One important thing is that we know these rules. Now we should know which ones applies to each country Lets suppose we know all this info. What I have been explaining in the comments is that, instead of to code test cases, would be more flexible to turn rules into metadata. Any metadata also needs a interpreter. I have said XML as candidate to modelate ...


1

Unit tests during code review are a poor substitute for unit tests during development. What you're suggesting makes a lot of sense, intuitively. What's the review for? To check that the code is good. What are tests for? To check that the code is good. So why not combine the two? Here's why. Bringing code under test is hard work. Writing code that just ...


1

In short, you should test your application, period. Whether you test your regex with automated tests that run it in isolation, as part of a bigger black box or if you just fiddle around with it by hand is secondary to the point that you need to make sure it works. The main advantage of unit tests is that they save time. They let you test the thing as many ...



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