Tag Info

New answers tagged

0

The only advantage of statement coverage is that it is much easier to calculate than other coverage variants. You just need to know if some line of code was executed and calculating coverage ratio is as simple as counting statements that were executed and total count of statements. With other coverage variants, you have to take account code before and after ...


3

Fixtures. The setUp and tearDown methods are for creating or cleaning up your fixtures. If they live in memory, cleanup is easy ;) but if your fixtures live in the database, then both setting them up and tearing them down can be a little more involved. (the last bit was to pad the answer, because "Fixtures" wasn't enough characters)


3

In terms of "how deep should QA go", it really depends on the people involved and what kind of teams you have, as well as the project code base. At my current job, we don't really like the term QA any more because we feel that we are all responsible for ensuring quality. Our developers practice TDD and unit test as much of the code base as we can (as well as ...


10

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc... Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was ...


0

I think that's a bit like asking if emacs is agile. The two don't really equate. If you are into the context-driven testing movement, then exploratory testing is one sort of testing you might do given the current context. Exploratory testing, in and of itself, isn't context-driven testing. It is exploratory testing, much like unit testing also isn't ...


2

At some point in time, someone has to make a decision how the UI has to look like. If this is done iteratively step-by-step in a dicussion between the customer and your team, fine - that is a feasible, pragmatic way. Whenever the decision is made for a particular part of your UI, you can start creating the tests. I end up creating the Automated test code ...


1

...when someone first clones a repository the unit tests fail so they have to figure out how to mount things with a certain name and the syntax used to build the testing path file. First, just to have a consistent terminology: This kind of test (large external dependencies, real data) is usually not considered a unit test, but rather an integration ...


0

Depends on what you call an application. If you mean, an interactive program where you need to be certain that the real-time behaviour is exactly such and such under any given circumstances, then it's basically impossible to proove there aren't any bugs in it. I suppose it would be possible if you could solve the halting problem, but you can't. However, if ...


4

Not all bugs are created equal so you need to sort out the wheat from the chaff. Expectations Many bugs are raised simply due to a shortfall in what the software does and what the end user is expecting. This expectation comes from many areas: using other software, incorrect documentation, over-zealous sales staff, how the software used to work etc etc. ...


0

Defects have existed from the beginning of software development. It's hard to tell from your question to what extent and what severity the defects effect the usability or functionality. Defect-free programs exist, but just about any non-trivial system will have defects. You will have to decide upon some sort of prioritization and likely will have to ...


14

The closest you get to a bug-free application, the more expensive it gets. It's like targeting 100% code coverage: you spend the same amount of time and money getting from 0% to 95%, from 95% to 99% and from 99% to 99.9%. Do you need this extra 0.1% of code coverage or quality? Probably yes, if you're working on a software product which controls the cooling ...


1

It might be useful to examine the testing artifacts that ISO 12207 demands under Verification and Validation: Verification 7.2.4.3.2.3 Code verification. The code shall be verified considering the criteria listed below: a) The code is traceable to design and requirements, testable, correct, and compliant with requirements and coding ...


5

In the opening sections of the paper that you quote, Boehm states: There is very little agreement in the software field on the definitions of the terms "verification" and "validation." Boehm defines the terms verification and validation as he intends to use them in the rest of the paper, in order to be able to clearly present the rest of the writing ...


1

When the NAS isn't working, is slow, or is down than we can't run a full test. Obviously, this can only be solved by copying the 5GB from the NAS to your local drive. But there is no need to do this manually. The second reason is that when someone first clones a repository the unit tests fail so they have to figure out how to mount things with a ...


3

How to handle large files in a build chain I like to use a build tool that does dependency management - such as maven or gradle. The files are stored in a web repository, and the tool takes care of downloading and caching automagically when it encounters the dependency. It also eliminates extra setup (NAS configuration) for people who want to run the test. ...


1

You can write a small shell script (~5 lines) to launch a browser and capture the window with imagemagick's import. I use this for Firefox: firefox -no-remote "$1" & sleep 10 window_id=$(xwininfo -tree -root | grep Navigator | awk '{print $1}') import -window $window_id "$1.png" wmctrl -c Firefox The only unusual thing here is using wmctrl instead of ...


0

As of December 2014, the best options for cross-browser CSS regression testing seem to be: CrossBrowserTesting.com Proprietary cloud service; Costs money Sounds like it can do the diff-ing and approval management and norm/reference/baseline tracking for you? I haven't actually tried this service out. WebdriverCSS A Selenium-based tool that offers a web ...


6

Of course it is OK! You always need functional/integration test that exercise the complete code path. And complete code path in this case means including evaluation of the generated code. That is you test that parsing x = 2 + 3 * a produces code that if run with a = 5 will set x to 17 and if run with a = -2 will set x to -4. Below this, you should do unit ...


4

Unit tests allow you to pin point specific items that break and where in the code they broke. So they're good for very fine grained testing. Good unit tests will help decrease debugging time. However, from my experience unit tests are rarely good enough to actually verify correct operation. So integration tests are also helpful to verify a chain or ...


21

You're going to find yourself writing a lot more tests, of much more complicated, interesting, and useful behavior, if you can do so simply. So the option that involves var input = new Parser().ParseStatement("x = 2 + 3 * a"); is quite valid. It does depend on another component. But everything depends on dozens of other components. If you mock something ...


0

It seems that tests basically express the same thing as the code, and hence is a duplicate (in concept, not implementation) of the code. This is not true, tests describe the use cases, while the code describes an algorithm which pass the use cases, so which is more general. By TDD you begin with writing use cases (probably based on the user story) and ...


0

Unit tests should not include a duplication of the code under test, as has been noted already. I would add, though, that unit tests are typically not as DRY as "production" code, because setup tends to be similar (but not identical) across tests ... especially if you have a significant number of dependencies that you're mocking/faking. It is of course ...


0

If you think your test code is too similar to your implementation code, this may be an indication that you are over-using a mocking framework. Mock-based testing at too low a level can end up with the test setup looking a lot like the method being tested. Try to write higher level tests that are less likely to break if you change your implementation (I know ...


4

I think there's not much more, you might be "close" to the complete picture (at least the picture that I'm aware of), so I'll give you a list of buzz-words. no testing: Don't use! test-last: old crap from the past, like doctors not washing their hands or accountants attempting to skip double-entry book keeping. Better than no testing, but still don't use. ...


0

For testing XSLT I rely on two command-line tools: the hopefully familiar xmllint for validity and xmlstarlet for data validation. The latter allows you to create shell scripts to pull out data elements for testing within that script. You can use arbitrary XPath and so test things like the number of elements in an output document. Thus you can create a ...


1

Mocking serves a number of purposes: make the test run fast make sure all services required by the test are always available make sure defects don't make debugging your module too complicated If none of these is a substantial problem in your case, don't mock. Why not? Because creating mocks costs time mocks induce additional effort when changing your ...


3

Treat them as an ordinary database. When you are testing business code which uses a database, you mock the database in order to test just the business code (as well as for making tests slightly faster). The same applies to key-value stores. What you may have seen is: Either integration and system tests which, indeed, rarely use mocks. Usually, a system ...


0

Part of BDD is applying the 3 Amigos approach where the stakeholders collaborate to produce the acceptance criteria. QA/Dev can write the step code to make scenarios execute as acceptance tests. Where is the value of QA to execute manually the same acceptance tests that a BDD tool will execute automatically? The value add of QA is to validate those ...



Top 50 recent answers are included