Unit testing or integration testing?

[yimiyimi88]

Here it says that this example is more of an explanation of framework than best practice because of the conflation of integration/unit testing concepts: http://docs.flexunit.org/index.php?title=Using_Asynchronous_Startup
My question is, how do you define a line here between unit testing and integration testing? What kind of UI components asynchronous tests are then considered to be unit tests and not yet integration tests? Many books recommend having 100% code coverage with unit tests. How would this example look like, to be considered only a unit test and not integration test?

[mlabriola]

this is the territory of opinion instead of absolute, but let me give you mine. those books that mention full unit test coverage probably arent working with flex. to me, a unit test is a test of a piece of code completely independent of external code dependencies. in other words, you must be able to isolate the code to ensure that external influences cannot affect you tests. this is first handled by architecting your code to be isolated and, during testing, using mocks and other such concepts to ensure isolation. the important take away here is that testable code is an architecture before an operation.

the flex framework is not testable code, at least not from a unit testing level. it has intertwined dependencies and uses implementation over interface, which makes mocking horrific. therefore, components built upon the flex framework cant be unit tested as a whole. i advise that, when writing components, you separate your code. keep in mind the idea of separation of concerns and keep your visual code in the component, but all logic and extractable code should be in other classes. you can then unit test the other classes and eventually integration test the entire component.

remember a flex component works with the layout manager, style manage, resource managers and many other pieces. the moment you have all of these pieces, you are testing their integration

sorry about spelling, typing from my phone,

mike

[yimiyimi88]

Thank you Mike, Your answer was really helpful!

So, testing UI components using FlexUnit4 is closer to Integration testing than unit testing. In fact you can not perform UI component unit testing at all because of the intertwined dependencies and impossible mocking.

I have one more question, we are trying to introduce some automatization for building and testing + we will use maven. Do you think it would be beneficial to use flexunit4 to do this kind a "integration" testing I mentioned in this post? It would be nice to have UI components covered with test code and included in maven reports. Since this is an open source project it is also good that everyone is able to download the project and run the tests.

However we were planning to use some functional testing tool like HP QTP as well, so is there any need to write flexunit4 tests for UI components at all? Are there any benefits by doing both? After all with flexunit4 you can test on component level and with external tools you usually test runable application - the black box style. Thank you for your recommendations!

[mlabriola]

The question about which levels of testing to do are really dependent upon you. Let me explain a bit more.

If you are building an application, and only an application, then functional testing probably covers most of your needs. In an application environment, you have a relatively narrow pathway of options and interactions that a user might follow. So long as you test those options well, your app will probably work as well.

Where I see the real value of unit testing is testing for the unknowns. If you have a class that will be used in multiple applications in multiple ways, or perhaps it is intended to be a reusable class where others in your organization will use it in the future, then you want lower level testing. You want to have the best coverage you can because you want to know that, regardless of the way someone chooses to use the code, it will likely function or at least fail gracefully.

The same is true for integration. If I am creating a Flex component, then I can unit test part of it, but not all. So, I want to use integration tests to ensure that it works in as many circumstance as possible. Further, Flex components have a life cycle, so testing them when they are not on the display list isn't really a valid test..

So, to summarize, I see unit and integration w/Flex about testing possibilities and trying to achieve realistic code coverage for known and possible use cases. I see functional testing as testing those components in very specific use cases.

Which do you need? Depends. Are you developing reusable components across (n) projects, likely the first 2 and maybe the last. Are you an application developer testing that an application works in documented business cases? Just functional will likely work.

Hope that helps,

Mike

[yimiyimi88]

Thank you Mike! I think we will go into the direction of writing tests for our publicly avaliable open source framework UI components and we will use QTP internally for applications based on this framework that are not publicly available.