0

I am a second year Computer Science student currently on a placement and I am currently developing a Java EE application that collects meta data from several sources and then visualises the data. This is the first major programming project I have done. (Nothing like university with 200 lines of code for an assignment)

I am about half of the way through the development of this application and have learnt an incredible amount. One of those things is TDD. From learning this I have gained an understanding of how important testing is and how it can help speed up development.

The reason for the back story is to cover for my ignorance. My university hasn't taught it to me and it is non-existent at my work place. I am incredibly keen in making sure I follow best practice in everything I do and I would like to include it in my application as I feel it would bring many benefits.

The problems I have though, are:

  • My application (like many I am sure) will contact several external sources. Take my message consumer for example. It will contact up to 3 remote restful interfaces and a database. The URLS of these apis are dynamic and are only accessible once the application has loaded the properties file (which has to be modified by the application user).
  • I feel it would be difficult to retro-fit the tests on a system that hasn't been built in a TDD manner.
  • I practically don't have time to retro-fit/ learn how to do advanced TDD with java EE applications.
  • As it isn't practice at all in my work place I wouldn't be able to ask questions or be corrected on if what I was doing is best.

Should I just accept defeat on this project as I am too far in and going forward I should just enforce TDD on everything I can? (where it is practical of course).

I'm just concerned that any future potential employers might look at my work from this placement and think less of me because lack of good practice. (Not worried what the current company thinks as it isn't a thing and they are very happy with my project.)

  • 1
    Unit Tests cannot (and should not) cover everything. You can look into Mocking things that cannot be unit tested (like interactions with external systems you mentioned), but that can be quite a lot of work and is often difficult to get right. You will need Integration Tests to veryfy whether the assumptions you built into your mocks really hold. – Hulk Jan 23 '16 at 14:26
4

There are a lot of articles, books, blogposts, conference talks... that deal with this issue. Michael Feathers' Working Effectively With Legacy Code is by many considered to be one of, if not THE best books on the subject. There is a twelve-page PDF available for free online that formed the basis of the book and should serve as a good starting point. Don't be fooled by the term 'legacy code': yesterday I've seen code written just last week that wasn't properly structured and hard to test and I consider that 'legacy' as well.

Remember that TDD, as any aspect of development, is also a learning experience. I've been doing TDD for years now and my style has grown and evolved as I've written and maintained test code, read books, heard talks on the subject, etc... In that regard you probably shouldn't be concerned with future employers. As long as you can prove that you evolve and learn (which you do in adopting TDD-practices) they probably won't hold it against you.

  • Thank you for the answer! I will look into what you have referenced which should hopefully help me move forward with this issue. – Softey Jan 23 '16 at 15:09

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.