Hot answers tagged

9

It's a matter of perspective. Writing tests for our code forces us to decouple the code. You COULD view this as "code that exists only for the tests", but I think this is misleading. What you're actually doing is decoupling your code. You are removing hard dependencies and getting rid of the headaches that come with code that news up everything it needs. ...


8

Typically you have multiple pipelines - you run "quick n dirty" unit tests as devs commit changes. When they say they're ready to merge their changes into a testing branch, you run a more "slow n steady" integration tests (and any other analysis tools you like). If these pass, you merge the testing branch onto some QA branch where you can generate deliveries ...


4

Go for it - Jenkins is an awesome choice for CI server, is easy to set up and work with. It doesn't take much server resource either. What CI gives you is a computerised 'build person' who can take your code from a repository and build it without your assistance. If you quit or get hit by a bus, this means that your code will still be usable without ...


4

I think it's an excellent mechanism to use. You're going to be able to confirm that your own builds (if no-one else's) will work in an isolated, reproducible environment. It'll check if you forget to commit work in your SCM system, and that the builds and tests all work in a controlled environment, independent of your personal environment. If your tests take ...


4

It should be pointless. But you should be making sure handler calls what validator needs called. For unit testing you should be testing in isolation. That means you'll need a stub (or mock) validator to hand to handler when you test handler. You don't check validator business logic when testing handler. You test that handler calls validator (in this ...


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.


2

If you encapsulate all IO operations in a small class with an interface and inject it to the archiving class you can mock calls to the IO system during testing. public class Archiver { public IFileSystem Filesystem { private get; set; } public void DoWork() { //business logic here } public Archiver() { Filesystem = new ...


2

Obviously I want to make sure that the validator is called when the handler does its thing Then mock the validator and test that it is called with the right parameters. No need to test the validator itself twice. On a related note, unit tests have their true value in test driven development. It sounds like you are writing the tests after the code ...


2

There's a good getting-started tutorial here. In the tutorial they use QEMU, an x86 emulator. It's not a full-featured as VirtualBox, but if you're just testing a boot loader, it may be better as it's a more lightweight package and you'll probably be in a pretty tight edit->compile->test loop.


1

I'd separate test stability from test duration, they matter in different manners. Test stability is critical if the test is executed rarely and there aren't enough datapoints to actually measure the stability. Checken and egg problem. But if enough execution datapoints exists to allow an estimation of the test stability then it can be incorporated in the ...


1

This one actually has a very straightforward answer and it is related to the level of caching. What you will observe when the caching is correct is the absence of requests at the target of the requests. So, it comes down to the hackneyed QA phrase of "expected results." If implementing a cache at the web tier, then I would expect that items subject to ...



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