New answers tagged

-1

I am in favor of using third person, present tense without a qualifier. My main argument is that: A test is a story. A story consists of scenes. Each scene describes: subject context action Example: DESCRIBE: getReceipt function CONTEXT: receipt exists IT: returns the receipt Just like a good story, a good test is easy to read. A story ...


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


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


0

Ultimately there is also a question of business value. The purpose is of the test is ultimately to be able to comply with the rules as code, software environment, staff and scale change. So you surely have tests up to date for major markets such as US, Germany, UK, China. Maybe also for Luxembourg, because they have I important decision makers. Probably not ...


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


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


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.


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


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


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

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

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


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


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


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


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


-5

If you have to ask, the answer is yes. Suppose some FNG comes along and thinks he can "improve" your regex. Now, he's a FNG, so automatically an idiot. Exactly the kind of person who should not touch your precious code under any circumstances, ever! But maybe he's related to the PHB or something, so there's nothing you can do. Except you know the PHB is ...


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


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


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


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


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.


-2

On the other hand: they themselves are seldom part of the interface of some unit. It might be better to only test the interface and do that in a way that implicitly tests the regexes. I think with this you answered it yourself. Regexes in a unit are most likely an implementation detail. What goes for testing your SQL probably also goes for regexes. ...


0

This isn't true. It's much better to place your unit-tests along side the production code when the production code especially when the production routine is pure. If you're developing under .NET for instance, you could put your test code in the production assembly, and then use Scalpel to remove them before you ship.


2

About your 80%. I assume it is about code coverage, right? The question is also can you test all business logic through the UI? Is every code path really available through UI actions? There might be logical path that are not executed at all. So maybe 80% is close to the maximum possible? And normally unit tests are used to test business logic I think.


0

Separate the things that vary from the things that don't. It is bad to rewrite the same tests for multiple pages. It is bad to try to write a test to fit every page. What you need is a way to associate the test with the pages they are valid for that doesn't involve rewriting them. That way if test A is valid on pages 1, 4, and 7 it's only tested on 1, ...



Top 50 recent answers are included