Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>It sounds like the problem is not with unit testing, but with your tooling/platform. I come from a Java background, so I don't have to re-write my queries just to satisfy unit tests.</p> <p>Testing Json is a pain in the you know what. If you don't want to test it, don't ;) Testing is not about 100% coverage. It's testing the stuff that really needs to get tested. You are way more likely to get a bug inside of a complicate if expression than adding things to a map, and then getting it converted to json.</p> <p>If you test that the map is getting created properly... there is a really good chance that the json is also correct. Of course, it won't always be, but you'll know that once you run it and it works. Or not. It's really that simple.</p> <p>I can provide a real comment on the 3rd problem though. You really don't want to create massive object graphs. But there some ways to do it.</p> <p>Create a singleton called ObjectMother. Have methods like ObjectMother.createProject(). Inside, you create the dummy project instance. That way, 12 tests can use this method, and then you only have to change it in one spot. Remember, test code needs to be refactored!</p> <p>Also, you might look into something like dbUnit. Well, that's what it's called in the Java World. The idea is that before every test is run, it puts the database in a known state. And it does this automatically in the setup/teardown of your tests. This means your test code can immediately start testing. The actual dummy test data is in a script or xml file.</p> <p>I hope that helps.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload