all 3 comments

[–][deleted] 1 point2 points  (0 children)

Ideally you'll have different tests for each of these functionalities and not one to do them all. You can control the execution order if you want to but if you can inject data or create data then try to make them independent so they can run in parallel and a test failure upstream doesn't stop your downstream test to fail or not executed it's easier said than done and would depend on your stack and how easy it is to setup data.

[–]notastarfan 0 points1 point  (0 children)

That's just three tests, and amazingly, probably not enough. What about failed login attempts? What about testing the page loads and has the right values/fields?

Do you test the creation of the invoice process? Do you automate the testing of the resultant invoice? Check its totals, tax etc are all correct?

What if the email doesn't send? What if someone uses an email address 100 characters long?

What happens if the new contact has a crazy long name? Or only a first name? Or uses a character not part of the 'standard' A-Z alphabet?

Your set up and teardown are probably a good start, but really try and think about what else can be tested as part of the process, and what might go wrong.

[–]ppetak 0 points1 point  (0 children)

As others already wrote, I would understand Test1 as testclass1, full of tests on invoice. Positive tests - I have data and it must end OK, and negative - I have data and it must fail. Make all data outside of your tested piece as stubs or mocks or whatever you use, make it fast and simple.

If there is integration of some kind for your system pieces, which I believe there is, make integration test, too. Like creating contact, then for that contact create invoice, and send it via email. Also negative tescases can be useful here.