Page Operations
Browse Space | JigZaw - Agile Testing done Right |
|
Documentation
Presentations |
Tools and Implementation |
Grouping and Categorizing
|
Spend less time on integration testing.
|
Test categorization
|
Remote centric architectureYour system has:
Standalone application:
|
Traditional 3 layer webserverFix the problem with end-to-end testing.
|
Enterprise TestingWhere manual testing is regarded as the only solution. How JigZaw can automate some of this testing.
|
Concept
Implementation
- Groups and when to run them - TODO update according to the timeline view
Grouping and Categorizing
- Standalone application example - not relevant in this form
- Web Application JigZaw - not relevant in this form
Other
Questions and Answers
Blackbox view on JigZaw
Improved communication (Norwegian notes)
JigZaw Test Levels
JigZaw Design Principles and Drivers
Groups and when to run them
JigZaw Introduction
Mapping between requirements and tests
JigZaw Service Test Tactics
JigZaw Software Stack
Standalone application example
Agile System Test Strategy
Blackbox view on JigZaw
Control state
How to combine JigZaw with the V-model
How to use JUnit Categories to implement JigZaw
How to use TestNG groups to implement JigZaw
Improved communication
JigZaw Categorization Matrix
JigZaw FAQ
JigZaw Intro
JigZaw principles applied to test maintenance
JigZaw results from system test
JigZaw timeline
JigZaw - unsolved challenges and TODOs
JigZaw Verktøy
Questions and Answers
System Test - Logical Overview
On the subject of test project organization (folder/package structure) I've been experimenting with BDD-style syntax to provide a more fluent guide into test behaviour:
Assembly/component:
MyComponent.Tests
Package/namespace:
.In_MockedContext.Given_CustomerRepository
TestFixture:
Get_Should
TestMethod:
Return_One_For_GetById
In test reports this produces nice statements that describe the tests:
MyComponent.Tests.In_MockedContext.Given_CustomerRepository.Get_Should.Return_One_For_GetById
MyComponent.Tests.In_SAP_IntegrationContext.Given_CustomerRepository.Get_Should.Return_One_For_GetById
MyComponent.Tests.In_SQL_IntegrationContext.Given_CustomerRepository.Get_Should.Return_One_For_GetById
etc. etc.
However after a while of implementing various tests at different levels I find that this syntax works well for System tests (high-level black box), but that it renders as complete nonsense (so far) for low level tests.
- Is "in_mocked_context" just rubbish because this is really just unittests?
- Shouldn't tests in different contexts just be designed for wiring with some IoC container?
- If so; how to structure the tests that test the stuff that gets wired
wow. I just confused myself.
Posted by It is nice to read that there are others that are thinking about how to improve how we work in this area.
While I'm not completely sure what you are asking here, I'll try to comment.
Note on BDD:
My experience with BDD-style naming is that often becomes too verbose. One trick is to multiple classes for the tests and put common context information into the name of the test class. I also prefer to use the BDD-syntax only on methods that map directly to the domain and not on "technical" tests. For example could Should.Return_One_For_GetById be replaced with getCustomerByIdOK.
1. In my implementations of JigZaw I try to reduce to use of mocks as much as possible. I find that the need for mocks can in many cases by eliminated by a different design and that the changes often lead to reduces coupling and improves cohesiveness.
2.
This subject is often easier to understand if we discuss concrete examples. According to JigZaw the different context part is only relevant when we are writing service and system tests (i.e. not unit tests).
There are multiple ways to implement the different context part depending on the actual problem. E.g. if data should be different in different contexts, the dataprovider concept in TestNG can be used. Another example is to test with different DBMSs, which can be done with Maven profiles.
I see now that there are to much to discuss here to efficiently communicate via comments. Give me a call or send me an email if you want to discuss these topics further. 
http://en.wikipedia.org/wiki/Model-based_testing