New answers tagged

1

I didn't want to use any framework / locator pattern I understand this, in fact I respect it. But it means your main will be a busy place unless you make good use of creational patterns. Good defaults can allow convention over configuration to simplify things. Surprisingly, this boils down to presenting humans with easy ways to use classes. That doesn't ...


1

So many answers and not even one Dijkstra's quote: Testing shows the presence, not the absence of bugs. Therefore, it depends. If the code was tested properly, most likely this bug would not exist.


0

(I'm not too well versed in PHP, but this advice should overcome language barriers) How would you test this class considering the header and the exit directives? So if that's the case, what would you be testing for this redirect method, the only option I can think of is testing if it's callable with $url and $data, is that all for unit testing? ...


1

The takeaway from this is to Fail Fast. We don't have the code, nor do we have many examples of prefixes that are or are not test branch prefixes according to the code. All we have is this: 089 - 100 => test branch 10B, 10C => test branch < 088 => presumably real branches > 100 => presumably real branches The fact that the code allows numbers and ...


13

Are you really asking, "would unit tests have helped here?", or are you asking, "could any kind of tests possibly have helped here?". The most obvious form of testing that would have helped, is a precondition assertion in the code itself, that a branch identifier consists only of digits (supposing that this is the assumption relied on by the coder in ...


2

Congratulations, your testing has now progressed to the stage where 'integration testing' is required. You have mentioned that in addition to u it testing you have done some general testing so far as well and have also put everything together and noticed that the testing reveals undesirable performance. Integration testing is all about how all individual ...


-1

I think a unit test here would have ensured the problem never exist in the first place. Consider, you have written the bool IsTestData(string branchCode) function. The first unit test you write should be for null and empty string. Then for incorrect length strings then for non integer strings. To make all those tests pass you will have to add parameter ...


0

An assertion built-in to the run-time might have helped; for example: Create a function like bool isTestOnly(string branchCode) { ... } Use this function to decide which reports to filter out Re-use that function in an assertion, in the branch-creation code, to verify or assert that a branch isn't (can't be) created using this type of branch code ‼ ...


27

No. This is one of the big problems with unit testing: they lull you into a false sense of security. If all your tests pass, it doesn't mean your system is working right; it means all your tests are passing. It means that the parts of your design that you consciously thought about and wrote tests for are working as you consciously thought they would, ...


-1

I think the problem with the code is that the underline object had to broad invariant to start with. If I am going to receive only number I am going to store my data in an int, not in a string. If suddenly, somebody start feeding alphanumeric data my program will report the error very quickly (not compiling or with an exception). The fact that a unit test ...


4

I really doubt unit testing would make a difference to this problem. It sounds like one of those tunnel vision situations because functionality was changed to support new branch codes, but this was not carried out throughout all areas in the system. We use unit testing to design a class. Re-running a unit test is only required if the design has changed. ...


8

Type testing (the process of testing invariants using randomly-generated valid data, as exemplified by the Haskell testing library QuickCheck and various ports/alternatives inspired by it in other languages) may well have caught this issue, unit testing almost certainly would not have done. This is because when the rules for the validity of branch codes ...


71

The software had to handle certain business rules. If there were unit tests, the unit tests would have checked that the software handled the business rules correctly. The business rules changed. Apparently nobody realised that the business rules had changed, and nobody changed the software to apply the new business rules. If there had been unit tests, ...


10

No, not necessarily. The original requirement was to use numeric branch codes, so a unit test would have been produced for a component that accepted various codes and rejected any like 10B. The system would have been passed as working (which it was). Then, the requirement would have changed and the codes updated, but this would have meant the unit test ...


117

Unit tests could have caught that the branch codes 10B and 10C were incorrectly classified as "testing branches", but I find it unlikely that the tests for that branch classification would have been extensive enough to catch that error. On the other hand, spot checks of the generated reports could have revealed that branched 10B and 10C were consistently ...


0

tldr; The first "weak" version implies you wrote the entire implementation to pass the one test. You should use each of the brute force tests to drive your implementation, one at a time. Okay the long version. You tagged this with #TDD so I'll answer how I'd do this in a TDD based way. Generally you want to start with the simplest cases first and build ...


1

The language is immaterial. Whether your database changing code is testable is all that matters. In any language you can access the database in a way that makes testing difficult. Is knowledge of your particular database spread throughout your code (or is it located in one place)? Is it difficult to swap in a different database? How hard would it be to ...


1

ENABLED_SECTIONS is the way to go. Then you can easily switch them on for those who want them (yourself, colleagues, maintainers) and off for those who don't (the project's user). That's what we do & it works just fine.


3

The problem you describe is in no way restricted to unit tests, and when approaching this from a software engineering perspective, one might ask the more general question "We picked a certain framework as a platform for our program system, but when upgrading to a newer version, we run into lots of unexpected compatibility problems, because the vendor did ...


3

There is no clear definition of what is a "unit test". The definition I find most useful though is the that if an isolated unit of code (which might be a method, a class, or way more than that) can be tested without any external side effects, then its a unit test. The "litmus test" being, can I run many of these tests in parallel, without them affecting each ...


8

First, there is no strict, widely accepted definition of when a test is not a unit test any more - the boundaries are blurry and to some degree opiniated. However, my understanding of the word "integration tests" involves that there must be at least two "units" or "components" of code, and some production code which integrates them. An integration test then ...


1

ok we have some different terms here, so here's what's going on We have Unit Testing. Other levels are integration testing, performance testing, etc. rspec can be used for many of the above levels of testing, e.g. against models, controllers and views through Capybara features tests. the word 'spec' comes from specification which is at the heart of a test ...


4

From the comments we exchanged, it seems you are not just unfamiliar with the maths, but also with basic numeric computing discipline. First, for god's sake, don't automatically pick an epsilon to makes your tests "pass". If you fudge the epsilons until the error is below epsilon, your tests don't test anything at all and you may ignore really bad precision ...


1

You could use a relative error. abs(actual / correct - 1) < epsilon But this doesn't work well if correct is very small. So you might have both an absolute and relative epsilon, accepting the result if it's smaller than at least one of them.


1

Using double precision floating points in both programs (which is the standard in MATLAB) on the same hardware for a deterministic algorithm is a minimum requirement to get similar results in both programs, assumed you are very pedantic in implementing each computational operation from your MATLAB program in a 1:1 fashion in your C++ program. However, you ...


2

Mock the externals for your unittests, where applicable It all depends on what the external library does for you. For example, if you have a class that depends on an external library that works with the file system you probably want to mock that and not perform any actual filesystem operations in your unittest. If you have an external library that does ...


6

Look at the following diagram. It illustrates the relationship between Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD): Notice that the inner loop, TDD, is enveloped by the outer loop, ATDD. Requirements (illustrated by the Acceptance Criteria box) drive the creation of automated acceptance tests, which in turn drive the ...


0

Here's an example that I'm doing to Fake the Id property of my entity. A.CallTo(() => _fakeRepository.FindAll()).Returns((new List<HighSchoolType>()).AsQueryable()); Guid fakePublicHighSchoolId = Guid.NewGuid(); var fakePublicHighSchool = A.Fake<HighSchoolType>(); A.CallTo(() => fakePublicHighSchool.Id)....


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


8

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



Top 50 recent answers are included