Tags : Browse Projects

Select a tag to browse associated projects and drill deeper into the tag cloud.

PowerMock

Compare

  Analyzed about 2 months ago

PowerMock allows you to unit test code normally regarded as untestable. For instance it is possible to mock static methods, remove static initializers, allow mocking without dependency injection and more.

67.7K lines of code

9 current contributors

about 2 months since last commit

16 users on Open Hub

Activity Not Available
4.8
   
I Use This

cmocka

Compare

  Analyzed 23 days ago

A unit testing framework for C with mocking. cmocka only requires a test application is linked with the standard C library which minimizes conflicts with standard C library headers. It is the successor (fork) of cmockery.

7.01K lines of code

8 current contributors

about 2 months since last commit

3 users on Open Hub

Low Activity
4.0
   
I Use This
Licenses: No declared licenses

JavaStubs

Compare

  Analyzed about 6 years ago

Provides method stubbing for concrete Java classes, intended for use with JUnit 4.

5.64K lines of code

0 current contributors

almost 8 years since last commit

1 users on Open Hub

Activity Not Available
5.0
 
I Use This

amop

Compare

  Analyzed 12 months ago

AMOP 0.3 is an Automatic Mock Object for C++. News: It works in GCC now...Please go to BuildInstructions Page to know more. By using ABI and template techniques, it can simulate a pseudo-"Reflection" which is normally not support in C++ . The main differences between AMOP and other mock ... [More] object library is that, users DO NOT need to implement the interface of the object which to mock... Please go to BasicUsage to know more. For any problem or feature requestion, you can leave a comment on GeneralDiscussion or go to amop google group. . [Less]

17.4K lines of code

0 current contributors

about 8 years since last commit

0 users on Open Hub

Activity Not Available
0.0
 
I Use This

m0cxx0r

Compare

  Analyzed 12 months ago

A library for automatically creating mock objects in C++, setting expectations for calls on those objects and subsequently verifying that the expected calls were made.

934 lines of code

0 current contributors

over 8 years since last commit

0 users on Open Hub

Activity Not Available
0.0
 
I Use This

snaptest

Compare

  Analyzed 9 months ago

Snap Unit TestingSnapTest can be obtained via the following repositories and methods: Git Repository: git://github.com/Jakobo/snaptest.git A browseable version of the history is available at http://github.com/Jakobo/snaptest "Mission Statement" of SortsTo put it simply, unit testing should ... [More] be transparent. There shouldn't be the complexity of test harnesses and coding out stub files. This functionality should be there if you want it, but the barrier to writing tests should be so low that it becomes easier to write the test than the code itself. It is on this philosophy that SnapTest was built. These are some of the goals of SnapTest and the SnapTest project (or at least a concept of what we are trying to do here) in no particular order: Build a PHP unit testing framework Create a 0-effort harness. Easy to run the code, easy to get results Maintain transparency in the code and the community Be as non-intrusive as possible Be memory efficient Link to complex infrastructures easily Take advantage of the OO structure PHP 5 provides Emphasize end-users as one of the most important resources Promote unit testing in a non-oo PHP world Code quickly; it's a snap. [Less]

5.27K lines of code

0 current contributors

over 6 years since last commit

0 users on Open Hub

Activity Not Available
0.0
 
I Use This

mockasin

Compare

  No analysis available

We are still working on making this library downloadable. For now, see Mock4AS, a simple implementation of a Mock Objects for AS3. IntroductionMockasin is a library that provides an easy way to use Mock Objects for given interfaces in AS3. Mock Objects simulate parts of the behavior of dependent ... [More] components, and are able to check whether they are used as defined. A Component can be tested in isolation by simulating its dependent components with Mock Objects. Mockasin BenefitsSupports refactoring-safe Mock Objects: test code will not break at runtime when renaming methods Supports return values and exceptions. Supports checking the order of method calls, for one or more Mock Objects. Mockasin Drawbacks (To Do List)Hand-writing classes for Mock Objects is needed. We are currently studying alternative solutions to remove the need for Hand-writing Mock classes. Mockasin by default supports the generation of Mock Objects for interfaces only. Alternative approaches are being considered for those who would like to generate Mock Objects for classes. UsageMost parts of a software system do not work in isolation, but collaborate with other parts to get their job done. In a lot of cases, we do not care about using collaborators in unit testing, as we trust these collaborators. If we do care about it, Mock Objects help us to test the unit under test in isolation. Mock Objects replace collaborators of the unit under test. ExampleWe will use the Greeting example to illustrate the basic functionality of Mockasin. The Greeting component says Hello in any language. Greeting uses a Translator component to translate “Hello” from English to the selected language. E.g. greeting.sayHello(“Portuguese”, “Paulo”) should return “Ola Paulo” ITranslator is an interface containing the translate method – parameters from, to and word, which returns the translated word; e.g translate(“English”, “Portuguese”, “Hello”) would return “Ola”. Greeting.as package com.google.mockasin.samples.greeting { public class Greeting { private var translator:ITranslator; public function Greeting(translator:ITranslator) { this.translator = translator; } public function sayHello(language:String, name:String):String { return translator.translate("English", language, "Hello") + " " + name; } } } ITranslator.as package com.google.mockasin.samples.greeting { public interface ITranslator { function translate(from:String, to:String, word:String):String; } }At construction time, the Greeting component receives a ITranslator component, a concrete implementation of the ITranslator interface. This simple mechanism is called CDI – Constructor Dependency Injection; basically an instance of the dependent component (some ITranslator implementation) is being injected in the Greeting component at construction time. The following examples assume that you are familiar with the FlexUnit testing framework. Although the tests shown here use FlexUnit in version 0.8.5, you may as well use !ASUnit (release 20071011). The First Mock ObjectWe will now build a test case for the Greeting component and understand the basic functionality of Mockasin. Our first test should check whether the greeting in any language returns the expected result, according to the ITranslator translated “Hello” word. Let’s follow the test code and analyze line by line. (The complete example of our first mock object is provided in the next section.) package com.google.mockasin.samples { import com.google.mockasin.*; public class GreetingTest extends TestCase { public function GreetingTest() { }The import statement makes the Mockasin functionality available for the current Unit Test code. Make sure your project do include the Mockasin library or source code. public override function setUp():void { reset(); }The reset() function should be called in between tests to make sure expectations of one test do not interfere with other tests. If the the reset() function is not invoked, expectations will be carried over. Please consider the reset() usage while designing your tests. public function testGreetingInAnyLanguage():void { // Create the mock. var mock:MockTranslator = new MockTranslator();An instance of MockTranslator is created. Mockasin gain control over MockTranslator instances by means of MockTranslator extending MockObject. // Set expectations. expect(mock.translate) .withArgs("English", "Swedish", "Hello") .andReturn("Hej");This is how you set expectations on the mock object. In this sample, you are telling Mockasin that translate("English", "Swedish", "Hello") should be invoked for your mock object and it should return "Hej" // Inject the mock. var myGreeting:Greeting = new Greeting(mock);The Greeting component receives concrete implementation of ITranslator interface as a constructor parameter. Mock is an instance of MockTranslator, which implements ITranslator. // Execute and assert on greeting. assertEquals("Hej Martin", myGreeting.sayHello("Swedish", "Martin")); Keep in mind that this test is for the Greeting component. This line is verifying the greeting functionality. // Verify mock behavior. verify(); } } }The verify() function will verify all expectations set for Mock Objects occurred as specified. In case of a failure, an error – with a meaningful message - is raised and your test will fail. // Inner Class import com.google.mockasin.MockObject; import com.google.mockasin.samples.greeting.ITranslator; class MockTranslator extends MockObject implements ITranslator { public function translate(from:String, to:String, word:String):String { return handleCall(arguments, this); } }You are required to create a MockTranslator class. In this example, MockTranslator was created as an Inner Class (on the same file) of GreetingTest.as The MockTranslator class must extend from MockObject and implement the ITranslator interface. The interface method implementation should contain return handleCall(arguments, this); Future releases of Mockasin will attempt to remove the need to create the MockTranslator class. The Completed Greeting Examplepackage com.google.mockasin.samples { import com.google.mockasin.*; public class GreetingTest extends TestCase { public function GreetingTest() { } public override function setUp():void { reset(); } public function testGreetingInAnyLanguage():void { // Create the mock. var mock:MockTranslator = new MockTranslator(); // Set expectations. expect(mock.translate) .withArgs("English", "Swedish", "Hello") .andReturn("Hej"); // Inject the mock. var myGreeting:Greeting = new Greeting(mock); // Execute and assert on greeting. assertEquals("Hej Martin", myGreeting.sayHello("Swedish", "Martin")); // Verify mock behavior. verify(); } } } // Inner class import com.google.mockasin.MockObject; import com.google.mockasin.samples.greeting.ITranslator; class MockTranslator extends MockObject implements ITranslator { public function translate(from:String, to:String, word:String):String { return handleCall(arguments, this); } } [Less]

0 lines of code

0 current contributors

0 since last commit

0 users on Open Hub

Activity Not Available
0.0
 
I Use This
Mostly written in language not available
Licenses: Apache-2.0

NaturalSpec

Compare

  Analyzed about 6 years ago

NaturalSpec is a .NET UnitTest framework which provides automatically testable specs in natural language. NaturalSpec is based on NUnit and completely written in F# - but you don't have to learn F# to use it.

41.3K lines of code

1 current contributors

about 6 years since last commit

0 users on Open Hub

Activity Not Available
0.0
 
I Use This

mockitopp

Compare

  Analyzed about 1 year ago

MockitoPP C++ Mocking FrameworkA C++ mocking framework inspired by the ideas developed for Mockito written by Szczepan Faber, et al. The purpose is to provide similar construction semantics for creating mock objects leading to smaller, more readable test cases. It is designed to be a lightweight ... [More] framework allowing you to mock dependencies for a system under test using a simple descriptive domain specific language. The goal is to help create simpler, less brittle test cases; ultimately, leading to less maintenance overhead in the future. How Does It Work?MockitoPP uses ABI and template techniques to create mock delegate classes that intercept calls intended for any abstract base class you care to model. The techniques used to construct the mock objects are similar to the techniques used by Automatic Mock Object for C++ (amop), Hippo Mocks and Member Function Pointers and the Fastest Possible C++ Delegates. By exploiting the compiler's ABI class layout we can dynamically construct a mock delegate class to provide minimal stubbed functionality used during unit testing. Requirementsoptional: Google C++ Testing Framework (if compiling/running unit tests) optional: Hamcrest (if using hamcrest argument matchers) optional: C++ Technical Report 1 or Boost C++ Libraries (if using regex argument matcher) LimitationsThis framework really only supports pure virtual abstract base classes (i.e. interface). The mocking construction only works for virtual functions declared in the target class to mock. You cannot use it to stub calls to non-virtual functions. In some cases it may be possible to mock a class that is not a pure abstract base class (i.e. hybrid class containing both virtual and non-virtual functions), but you may encounter unexpected results if other objects are expecting the mock object to operate under normal circumstances (i.e. maintain state) or have internal wired dependencies that operate on the object's state. [Less]

3.93K lines of code

0 current contributors

almost 4 years since last commit

0 users on Open Hub

Activity Not Available
0.0
 
I Use This

mockcache

Compare

  Analyzed 23 days ago

The Python dictionary-based mock memcached client library. It does not connect to any memcached server, but keeps a dictionary and stores every cache into there internally. It is a just emulated API of memcached client only for tests. It implements expiration also. NOT THREAD-SAFE.

177 lines of code

2 current contributors

11 months since last commit

0 users on Open Hub

Very Low Activity
0.0
 
I Use This