title: How to reduce UI tests in Test pyramid without affecting the quality of UI delivery
body: <p>We have a big java based desktop application in our company that we are building test cases for. 
  We want to follow test pyramid approach as:</p>
  
  <p>1) We ask devs write a lot of unit tests (but don't verify where they have written good quality unit tests or not).</p>
  
  <p>2) We write service tests where we go through each and every line of the code and write Junit tests to test every possible method and condition in the code.</p>
  
  <p>3) We are planning to create UI tests to ensure the UI works correctly.</p>
  
  <p>I read a lot of blogs about test pyramid approach and understood that we should invest much less time in writing the UI tests as they are not good with testing ROI because they generally take a lot of time to execute and they are brittle due to their dependency over the UI elements. I absolutely agree on these points. </p>
  
  <p>But, the question is, when we say we need a much lower number of UI tests, do we mean we just need UI tests for priority-1 cases (or smoke tests)? On the contrary, the UI is the element the user interacts with so do we not need to make sure it is not broken in the first place? I mean, when we say we need to reduce number of UI tests, won't it affect the quality of the UI delivery?
  For example, I have written a lot of service tests and made sure the backend business logic is perfect but what if the UI is messed up? Is it not equally important?</p>