Tag Info

Hot answers tagged

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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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



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