I am a sole developer working with an offshore employer. I do realize the importance of unit testing (although haven't practiced before) but currently, the code hasn't ever been tested. The problem with the code is that it isn't what I call "been moduled well", some parts are really messy, extensive use of globals and the code doesn't really show loose coupling. If I am not wrong, the code might require heavy refactoring before being able to be unit tested. Also, it seems the employer, isn't quite interested in testing. He rather suggests to spend this time in building features.

So what I suggested to him is UI testing. Because UI testing is something we do every time, testing features, clicking, checking if something is not broke, it made sense to both of us to use it to automate the process of checking features and save us time.

Since I have never done UI testing before, I don't know what possible disadvantages might be associated with using just UI testing alone or will it be much beneficial at all?

  • How well can you automate those UI tests? – Christopher Creutzig May 5 '13 at 15:37
  • @ChristopherCreutzig: I can't tell about 'well'. I would be using CasperJS for that part which I think is much better than solutions such as Selenium IDE or Watir because of its headless nature. – Shubham May 5 '13 at 16:16
  • Hey, you are the developer, and you are talking about code written by you? So when you already know where the problem is, why don't you solve it? – Doc Brown May 5 '13 at 19:55
  • 2
    @DocBrown: I got the job in the middle of project. The messy code wasn't written by me. – Shubham May 5 '13 at 20:13
  • (Old question, I know). What do you do if there's no UI? I regularly venture into the embedded world, where (if you're lucky), your display is a tri color LED. Often times, you don't even get that. Mmmmmm...black box debugging. Now THAT can really tie your colon into knots. – CurtisHx Jun 5 '15 at 17:38

At my work, we started using UI tests in addition to our unit and integration tests. Of the three types, the UI tests take the longest to write and to run and catch the fewest amount of bugs. They are also extremely brittle, failing sporadically for no good reason.

Because they take so long to run and do not pass consistently, we found that it was not worth the effort to maintain them. Of course, this could be due to writing the UI tests poorly, or using a bad framework (we used visual studio Coded UI tests).

We have had much better success with unit and integration tests. In your situation, given that the code is not very modular, unit testing will be difficult as you mentioned. I think you would have much better success with integration and acceptance-level tests (test entire features at a level just below the UI).

  • 1
    They're also brittle because it's possible to change the UI very quickly. If the UI code is modular, you should only be testing what your application adds, and let the UI framework test the core functionality of UI elements – Old account May 6 '13 at 17:25
  • It depends on the kind of UI tests that you use. The Microsoft Framework for WPF UI testing is not much more brittle than a unit test. Also, the UI test catched most of the bugs when we used them. – Falcon May 7 '13 at 18:40

The biggest problem IMHO of UI Testing exclusively is that the permutations of things to be tested, even in a relatively simple app, are too great and the level too high to catch many potential defects. Code coverage is not going to be very high.

You will probably find and locate some major items that will inhibit the users in a few scenarios (best case, worst case run through), validation issues and what not. However, you won't find the things that say a Breaker would use to disadvantage your application and get into your data, for example.

Unit test, TDD, Functional Testing and other testing methodologies are designed around testing the code internally and at a more granular level. This makes the testing more complete and likely to catch the more insidious bugs that simple UI testing alone will miss. A combination of the above is your best bet. Sadly it doesn't sound like you will have to much choice unless you just do it. It sounds like there are severe time constraints as it is, but note that with only UI testing your time may run over regardless.

  • So, you suggest that UI testing will do more harm than good? – Shubham May 5 '13 at 16:14
  • 3
    Some testing is better than no testing. But just keep in mind that you will have a hard time getting good code coverage with UI testing alone. – Schleis May 5 '13 at 16:30
  • 1
    @Shubham no, not that extreme. It is definitely better than no testing at all. As Schleis said it won't give you good coverage and while it does well for what a user will face using the app, it won't uncover more insidious issues easily and so UI Testing alone is just not enough IMHO. I also find no reason to not actually do Unit Testing on the code your adding to the code base at the very least. In other words don't add more technical debt if you can avoid it. – Akira71 May 5 '13 at 16:37
  • I have a different opinion on that: We had both, Unit Tests and UI Tests, about 80% code coverage generally and the UI Tests found most of the errors. We had a really good tester writing them with good subsets of data. That's due to the nature of UT being integration tests, errors, which will never be detected with UT. If I had to choose between them, I'd choose the UI tests for an application with a rich UI. – Falcon May 5 '13 at 21:34
  • 1
    @Falcon: how did you avoid that UI tests to become brittle? To my experience, UI tests are fine as long as you have an UI as simple as the "Google entry screen", but completely unmanageable when you have a complex desktop application like Autocad. – Doc Brown May 6 '13 at 14:24

I would recommend picking up Michael Feathers' Working Effectively with Legacy Code. In the book he defines "legacy code," somewhat interestingly to me, as "code without tests". The impression that I get is that your situation is pretty common: not only is your code not covered by tests, but in its current state it can't be covered by tests. The book describes some ways to deal with this situation. I won't list them here because they a) are complicated and b) aren't committed to my memory.

What I do if I were you is put some of the code in a "test harness". At first I wouldn't even worry about adding meaningful tests at all. Just get to the point where you have one or two unit tests testing trivial parts of the system. Once you have that little beachhead, from there it's mostly a matter of expanding on the work you've already done (not to say that that is easy). It may feel pointless in the beginning, but a few semi-meaningless tests are better than no tests at all, and maybe after some gradual refactoring you'll have some meaningful tests.


UI tests are not what you're looking for. To get messy legacy code under test, you start writing Acceptance Tests. These are blackbox tests on the outer layer, but widely independent from the user interface. You can look at tools like Cucumber to get an idea about the approach.

As you're going to refactor and improve the code, you should add unit and integration tests for new code as you go along.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.