Tag Info

New answers tagged

0

Provided good TDD applied, test data tends to grow faster that actual code. Try splitting the test data into smaller pieces and reusing common ones. Yes, historically We are moving to dbsetup


0

The next step beyond 'testing every feature once' is systematic Pairwise Testing. This typically results in a set of a few tens of tests per feature, depending on the features visible complexity. This is obviously a lot more work, although not necessarily tens of times more work, at least if tests are automated. You will almost certainly need a suitable ...


1

IMHO you are asking the wrong question. Does it really make a difference for your software's quality or the efficiency of your tests if there is an "industry standard" or not? There is no widely accepted standard, nevertheless what you should ask yourself is: "does adding multiple different records for the same test scenario improve our process?" My ...


0

When we started building our product, we also implemented Kanban, and along with that, we implemented a complete test automation strategy. As a result, today we don't have testers in our team. Instead, developers must write test cases and automate them as part of working on any user story, enhancement or defect. Our definition of Dev Complete includes ...


4

Yes, testing absolutely should be part of the definition of "Done". Without question. From a purely agile standpoint, the right approach is for everyone on the team to contribute toward writing tests. The tester would be the one coordinating the effort, but it is the responsibility of the entire team to make sure the software is properly tested.


5

Firstly, a ratio of 10:2 is bad. From experience, a ratio of 3:1 or 4:1 developers to testers works well. You'll likely need at least one more tester therefore, otherwise the testing backlog will grow and either never get cleared, or you're cut corners somewhere. If you test tasks in the next sprint, you are implementing mini-waterfall or "scrumfall" as you ...


5

This is fairly common, if not typical. To answer what are several questions: What should be the right approach to track activities in such scenarios? Will features get done without QA but with defects? How can I track the efforts seamlessly? Should testing be part of "Done Definition"? What are the pitfalls if it is not? I would take an overall ...


1

The underlying problem that you are encountering is that you are testing everything in one go when comparing two text files. If any little thing changes, then the entire test fails and it is indeed tedious to find the part that broke and then fix it. You are doing system testing in jUnit. Not that it can't do it (though there are better testing frameworks ...


1

If the format of the log changes at all, it will break the unit tests When code changes, it breaks the corresponding unit tests. By following your logic to the extreme, you would avoid writing tests at all. Think about the goal of those tests. Are you testing: That a method actually logs something? That a method uses a proper message template? That a ...


3

Short-term solution: Leave things as they are. Badly written, brittle tests are much, much better than not having tests. On a scale from "no tests" to "tests so reliable they make you weep and do all your work for you", your existing test suite is much closer to "weep" than to "nothing". Middle-term solution: refactor. It's inconceivable that the analysis ...


0

Singletons are a bad idea in the Apple API. Objective-C does not support singletons, instead, you create one instance that blocks the formation of any others, a crude work around IMHO, that doesn't always work. I don't think is any better in Swift and given it has to support the Objc API, I doubt it. The preferred method to ensure a single instance is to ...


2

I've been in a similar situation, we ended up saving all input and output files to/from the system in production. With them in hand we could build a test setup and have a test harness (did running the input files still give the same output files). Then we could slowly start to refactor and uncover what the system requirements actually were and in the end ...


0

This is not completely related, but if you includes formal specification languages, you have benefits with annotating your code with formal invariants and contracts. See for example the ACSL reference manual, for C. The same goes for Ada which allows forall expressions that are not part of the language, but available for specifications: ...


1

If you are doing such testing, you will need a way to get the result data back to you. Feature toggling services won't necessarily provide such two-way communication. It seems as though you will need a two-way communication channel, and probably some kind of registration or log-in, such as by having a http server and requiring some frequency of communication ...


2

You're right, usability testing has a very different purpose. It consists of asking a user to manipulate a part of your product, and look at the way the user tries to achieve something. The goal is to ensure that user experience of your product is right and if there are things which could be improved to make the product easier, more intuitive or faster to ...


1

Is this good for the project? No. You have pointed out, yourself, that you have observed that it results in low-quality reports that are not targeted at required functionality, and that the testers end up, to compound the problem, scrambling to complete the work that they are actually "supposed" to be doing. If not, how can I (as a software ...


4

To me, though, it seems like overkill to pass in the time as an argument. You're right, and with mocking you can make the code testable and avoid passing the time (pun intention undefined). Example code: def time_of_day(): return datetime.datetime.utcnow().strftime('%H:%M:%S') Now let's say you want to test what happens during a leap second. As ...


1

Remember many rules in programming are essentially recommendations you can follow. So sometimes this is acceptable. Unit tests are called that way because they focus on testing single units of work. Generally, if you need more than one assertion per test case, you are structuring your test inappropriately. testing alternative code flows in the method, ...


4

From my experience, one of the most important and most far-reaching decisions you make when building a program is how you break the code down into units (where "units" is used in its broadest sense). If you are using a class-based OO language, you need to break all the internal mechanisms used to implement the program into some number of classes. Then you ...


8

Writing testable code is important if you want to be able to prove that your code actually works. I tend to agree with the negative sentiments about warping your code into heinous contortions just to fit it to a particular test framework. On the other hand, everybody here has, at some point or other, had to deal with that 1,000 line long magic function ...


0

When you write a test, how do you know it will detect a fail condition? The answer is "test the test". How you do that is to write the test first, see it fail, and only see it pass when the unit under test has been coded successfully (the red/green/refactor cycle mentioned in one of the other answers). Writing the code first and then the test leaves open ...


1

If you are going with SOLID principles you will be on the good side, especially if extend this with KISS, DRY, and YAGNI. One missing point for me is the point of the complexity of a method. Is it a simple getter/setter method? Then just writing tests to satisfy your testing framework would be a waste of time. If it's a more complex method where you ...


8

It certainly has a cost, but some developers are so accustomed to paying it that they've forgotten the cost is there. For your example, you now have two units instead of one, you've required the calling code to initialize and manage an additional dependency, and while GetTimeOfDay is more testable, you are right back in the same boat testing your new ...


11

At some point the value needs to be initialized, and why not closest to consumption? Because you may need to reuse that code, with a different value than the one generated internally. The ability to insert the value you are going to use as a parameter, ensures that you can generate those values based on any time you like, not just "now" (with "now" ...


4

A quality of well-written code is that it is robust to change. That is, when a requirements change comes along, the change in the code should be proportional. This is an ideal (and not always achieved), but writing testable code helps get us closer to this goal. Why does it help get us closer? In production, our code operates within the production ...


8

It's possible that not every characteristic which contributes to testability is desirable outside the context of testability - I have trouble coming up with a non-test-related justification for the time parameter you cite, for instance - but broadly speaking the characteristics which contribute to testability also contribute to good code regardless of ...


9

It may seem silly to say it this way, but if you want to be able to test your code, then yes, writing testable code is better. You ask: At some point the value needs to be initialized, and why not closest to consumption? Precisely because, in the example you are referring to, it makes that code untestable. Unless you only run a subset of your tests ...


63

Is writing testable code still good practice even in the absence of tests? First things first, an absence of tests is a way bigger issue than your code being testable or not. Not having unit tests means you're not done with your code/feature. That out of the way, I wouldn't say that it's important to write testable code - it's important to write ...


103

In regard to the common definition of unit tests, I'd say no. I've seen simple code made convoluted because of the need to twist it to suit the testing framework (eg. interfaces and IoC everywhere making things difficult to follow through layers of interface calls and data that should be obvious passed in by magic). Given the choice between code that is easy ...


41

Yes, it is good practice. The reason is that testability is not for the sake of tests. It is for the sake of clarity and understandability that it brings with it. Nobody cares about the tests themselves. It is a sad fact of life that we need large regression test suites because we're not brilliant enough to write perfect code without constantly checking our ...


1

I think you're running into a common pain point while testing and one of the reasons I dislike singleton implementations. Injecting these repository instances is a useful pattern allowing you to substitute test doubles or change the configuration of the API client in the future without needing to modify its implementation. However by implementing it as a ...



Top 50 recent answers are included